MNB-00003-29 - User Manual Tait DMR Tier 3

Tait TN9300 DMR
Tier 3 Trunked Network

System Manual
MNB-00003-29 · Issue 29 · October 2022

Contact Information Updates of Manual and Equipment
Tait Communications In the interests of improving the performance,
Corporate Head Office reliability or servicing of the equipment, Tait
International Limited reserves the right to update the
Tait International Limited
equipment or this document or both without
P.O. Box 1645
prior notice.
Christchurch
New Zealand
Imported into the EU by: Intellectual Property Rights
Tait Communications GmbH This product may be protected by one or more patents
Stipcakgasse 40 or designs of Tait International Limited together with
1230 Vienna their international equivalents, pending patent or
Austria design applications, and registered trade marks, for a
Imported into the UK by: complete list please check
Tait Europe Limited www.taitcommunications.com/our-resources/
Unit A, Buckingham Business Park, Anderson Road legal#Intellectual_Property
Swavesey The AMBE+2™ voice coding Technology embodied
Cambridge, CB24 4UQ in this product is protected by intellectual property
United Kingdom rights including patent rights, copyrights and trade
For the address and telephone number of regional secrets of Digital Voice Systems, Inc. This voice
offices, refer to our website: coding Technology is licensed solely for use within this
www.taitcommunications.com Communications Equipment. The user of this
Technology is explicitly prohibited from attempting to
decompile, reverse engineer, or disassemble the Object
Copyright and Trademarks Code, or in any other way convert the Object Code into
All information contained in this manual is the a human-readable form.
property of Tait International Limited. All rights
reserved. This manual may not, in whole or in part, be
copied, photocopied, reproduced, translated, stored, or Environmental Responsibilities
reduced to any electronic medium or machine-readable Tait International Limited is an
form, without prior written permission from environmentally responsible company
Tait International Limited. which supports waste minimization,
The words TAIT, TAITNET and the TAIT logo are material recovery and restrictions in the
registered trademarks of Tait International Limited. use of hazardous materials.
All trade names referenced are the service mark, The European Union’s Waste Electrical
trademark or registered trademark of the and Electronic Equipment (WEEE) Directive requires
respective manufacturers. that this product be disposed of separately from the
general waste stream when its service life is over. For
By using a Tait product you are agreeing to be bound more information about how to dispose of your
by the terms of the Tait Software Licence unwanted Tait product, visit the Tait WEEE website at
Agreement.Please read the Tait Software Licence www.taitcommunications.com/our-resources/
Agreement carefully before using this Tait product. If compliance#WEEE. Please be environmentally
you do not agree to the terms of the Tait Software responsible and dispose through the original supplier,
Licence Agreement, do not use the Tait Product. The or contact Tait International Limited.
full agreement is available at
www.taitcommunications.com/our-resources/ Tait will comply with environmental requirements in
legal#Tait_Software_Licence_Agreement. other markets as they are introduced.
Disclaimer
There are no warranties extended or granted by this
document. Tait International Limited accepts no
responsibility for damage arising from use of the
information contained in the document or of the
equipment and software it describes. It is the
responsibility of the user to ensure that use of such
information, equipment and software complies with the
laws, rules and regulations of the applicable
jurisdictions.
Enquiries and Comments

If you have any enquiries regarding this document, or
any comments, suggestions and notifications of errors,
please contact your regional Tait office.
2 Tait TN9300 DMR Tier 3 Trunked System Manual

© Tait International Limited October 2022
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Scope of Manual. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Special Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Associated Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Acronyms and Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
Publication Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.1 DMR Networks Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2 Network Principles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.2.1 RF Channels and Logical Channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.2.2 Control Channels, Traffic Channels and Alternate Channels . . . . . . . . 22
1.2.3 Physical Sites and Functional Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.2.4 Single Channel Base Station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.2.5 Simulcast Channel Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2 Network Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.1 Network Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2 Server Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3 Channel Spacing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4 Frequency Bands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4.1 TB7300 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4.2 TB9300 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4.3 TB9400 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.5 Power Supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.6 Base Station Comparisons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.7 IP Network Bandwidth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.7.1 Bandwidth Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.7.2 IP Bandwidth Data Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.7.3 Voice Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.7.4 Packet Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.7.5 Maintenance Traffic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.7.6 Node Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.7.7 Base Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.7.8 Network Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.7.9 Telephony Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.8 IP Protocols and Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.8.1 Additional Port Usage Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.9 IP Address Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.9.1 Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Tait TN9300 DMR Tier 3 Trunked System Manual Contents 3

2.9.2 Standard Address Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.9.3 Example IP Address Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.10 Network Linking Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.10.1 Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.10.2 Bandwidth Considerations and Recommendations . . . . . . . . . . . . . . . . 50
2.10.3 Effect of Not Meeting Timing Requirements . . . . . . . . . . . . . . . . . . . . 50
2.10.4 QoS/DSCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.10.5 Optimization Techniques for Reducing Bandwidth Requirements . . . . 53
2.10.6 Calculating the Delay Buffer Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.10.7 Effect of Delay Buffer Size on End User Audio Experience. . . . . . . . . 54
2.10.8 Ethernet Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2.11 Audio Level Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.12 Redundancy and High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.12.1 Geographical Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.12.2 Redundancy with Active IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.12.3 IP Backbone Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.12.4 License TNAS302 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.12.5 High Availability Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2.12.6 Network Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2.12.7 High Availability in Version 3 and Version 4 DMR Simulcast Systems 61
2.13 Speech Call Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
2.14 Data Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
2.15 Packet Data Transfer Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
2.16 Network Time Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
2.16.1 What is NTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
2.16.2 NTP Prevents Network Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
2.17 Centralized Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
2.17.1 AAA Security Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
2.17.2 How AAA Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
2.17.3 Network Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3 Network Features and Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

3.1 Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.1.1 DMR Tier 3 Trunking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.1.2 Interoperability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.1.3 DMR Standard Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.1.4 Tait DMR System Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.1.5 Ease of Migration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.1.6 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.1.7 Centralized Call Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.1.8 Channel Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.1.9 Hunting Behavior in Dual Mode and Fallback Mode . . . . . . . . . . . . . . 84
4 Contents Tait TN9300 DMR Tier 3 Trunked System Manual

3.1.10 Group Affiliation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.1.11 Group Call Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.1.12 Roaming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
3.1.13 Adaptive Vote Now . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
3.1.14 Failure Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
3.1.15 Single Site (DMR Access) or Fallback Mode . . . . . . . . . . . . . . . . . . . . 93
3.1.16 Call Amalgamation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
3.1.17 Direct Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
3.1.18 Security Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
3.1.19 Registration/Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
3.1.20 Background Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
3.1.21 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
3.1.22 Remote Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
3.1.23 IP Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
3.1.24 Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.1.25 Transmit Interrupt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.1.26 All Ident Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
3.1.27 Fast Polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
3.1.28 Jammed Channel Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
3.1.29 Shared Channel Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
3.2 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
3.2.1 Tait TN9271 Analog Gateway and G.711 Connector . . . . . . . . . . . . . 108
3.2.2 Dispatch Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .110
3.2.3 Telephone Interconnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111
3.2.4 Media/Voice Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114
3.2.5 Location Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116
3.2.6 Analog FM Base Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116
3.2.7 Inter-network Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117
3.2.8 Interface Connectivity Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117
3.2.9 Console Connectivity Protocol Comparisons . . . . . . . . . . . . . . . . . . . 122
3.2.10 MPT Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
4 Fleet Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

4.1 Managing Fleets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
4.2 Profiles and Service Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
4.2.1 Service Areas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
4.2.2 Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
4.3 Choosing a Numbering Scheme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
4.3.1 MPT 1343 Numbering Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
4.3.2 ANN Numbering Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
4.3.3 DMR Standard Numbering Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . 140
4.3.4 DMR Native Numbering Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

4.4 Numbering Scheme Conversion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
4.4.1 MPT 1327 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
4.4.2 MPT 1343 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
4.4.3 ANN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
4.4.4 DMR Standard Numbering Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . 147
4.5 Developing a Fleet Allocation Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
5 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
5.1 Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
5.2 Logging on to the Control Node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
5.3 Installing License Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
5.3.1 Checking That the License File is Correct. . . . . . . . . . . . . . . . . . . . . . 150
5.3.2 Obtaining the Host ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
5.3.3 Obtaining the license.dat File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
5.3.4 Installing the License File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
5.3.5 Licensed Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
5.4 Loading SSL Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
5.4.1 Version 3.xx and Version 4.xx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
5.4.2 Version 2 and Earlier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
5.5 Setting Up Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
5.5.1 Version 3.xxx and Version 4.xx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
5.5.2 Version 2 and Earlier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
5.6 Configuring the Local Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
5.7 Configuring Network Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
5.8 Configuring Telephony. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
5.9 Configuring Subscribers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
5.9.1 Adding Encryption Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
5.9.2 Adding Unit/Group Profiles and Service Areas. . . . . . . . . . . . . . . . . . 160
5.9.3 Adding Partition Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
5.9.4 Add Fleets, Units and Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
5.10 Configuring Nodes and Functional Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
5.11 Configuring Dual Control Channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
5.12 Configuring Transmission Trunking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
5.13 Configuring Transmit Interrupt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
5.14 Configuring Interface Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
5.14.1 AIS Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
5.14.2 Conventional Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
5.14.3 DIP Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
5.14.4 Inter-network Connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
5.14.5 TeamPTT Connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
5.14.6 IP Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
5.14.7 MPT Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

5.15 Configuring Centralized Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
5.15.1 Version 3 and Version 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
5.15.2 Version 2 LDAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
5.15.3 Version 2 RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
5.16 Configuring External Sites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
5.16.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
5.16.2 External Sites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
5.16.3 Configuration Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
5.17 Configuring an Alternate Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
5.18 Configuring Channel Authorization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
5.19 Configuring Switching Nodes for the First Time. . . . . . . . . . . . . . . . . . . . . . . . . 185
5.19.1 Logging on to a Switching Node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
5.19.2 Configuring the Switching Node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
6 Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
6.1 Stopping/Starting Node Controller Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
6.1.1 Version 3 and Version 4 Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
6.1.2 Version 2 Nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
6.2 Powering Down the Node Controller. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
6.3 Resetting a Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
6.4 Changing to a Local Time Zone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
6.4.1 TaitCentOS/Tait Ubuntu - Administration Application 1.16.01
and Later . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
6.4.2 TaitCentOS - Administration Application 1.14.xx and Earlier . . . . . . 189
6.4.3 Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
6.5 Downloading Call Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
6.6 Downloading Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
6.7 Downloading Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
6.8 Downloading General Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
6.9 Manually Downloading Files From a Node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
6.10 Creating/Restoring Backups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
6.10.1 Version 3 and Version 4 Node Backups. . . . . . . . . . . . . . . . . . . . . . . . 194
6.10.2 Version 2 Node Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
6.11 Upgrading Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
6.11.1 Version 4 (Tait Ubuntu) Firmware. . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
6.11.2 Version 3 (TaitCentOS) Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
6.11.3 Version 2 Nodes Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
6.12 Setting Up Short Form and Network Operator Numbers. . . . . . . . . . . . . . . . . . . 201
6.12.1 Short Form PSTN Calls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
6.12.2 Network Operator Calls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
6.13 Using Status Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
6.14 Barring Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
6.15 Setting up Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

6.16 Using Authentication Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
6.16.1 On Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
6.16.2 On Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
6.16.3 On Transmission Interrupt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
6.16.4 Reject Requests that Fail Authentication. . . . . . . . . . . . . . . . . . . . . . . 206
6.17 Replacing a Failed Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
6.17.1 Install and Configure Solaris 10/TaitCentOS/Tait Ubuntu . . . . . . . . . 207
6.17.2 Install the Node Controller Software . . . . . . . . . . . . . . . . . . . . . . . . . . 207
6.17.3 Configure the Node Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
6.17.4 Synchronize the New Node with the Control Node. . . . . . . . . . . . . . . 208
6.18 Subscribing to Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
6.18.1 Manual Group Assignment from the Node . . . . . . . . . . . . . . . . . . . . . 209
6.18.2 Radio Affiliation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
6.18.3 Dynamic Regrouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
6.18.4 Radio Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
6.19 Enabling Encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
6.19.1 Configuring Tait Radios for Encryption . . . . . . . . . . . . . . . . . . . . . . . 213
6.20 Adding SIP Lines to Outgoing Group Calls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
6.21 Upgrading DMR Express6 or DMR Express20 to DMR Full . . . . . . . . . . . . . . . 215
6.21.1 Before You Begin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
6.21.2 Upgrade Procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
6.22 Additional taitnet commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
6.23 Node Resource File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
6.23.1 Version 3 and Version 4 Nodes Resource File . . . . . . . . . . . . . . . . . . . 218
6.23.2 Version 2 Nodes Resource File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
7 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
7.1 Checking the Status of a Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
7.1.1 Using the Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
7.1.2 Using an ssh Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
7.2 Monitoring Calls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
7.2.1 Call Records File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
7.2.2 Call Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
7.2.3 Call End Reasons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
7.2.4 Call Close Reasons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
7.2.5 Call Handler IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
7.2.6 System IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
7.3 Investigating Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
7.3.1 Alarm File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
7.3.2 Network Alarms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
7.3.3 Radio Unit Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
7.4 Monitoring Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

7.4.1 Site Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
7.4.2 Channel Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
7.5 Monitoring Site Performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
7.5.1 Daily Site Details Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
7.6 Monitoring IP Links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

Preface
Scope of Manual
This manual is intended to provide a system-level introduction to TaitNet
DMR Trunked (Tier 3) radio systems, which are networks of IP
interconnected sites that enable radios with trunking capability to
communicate with each other.
Special Information
“File > Open” means “click File on the menu bar, then click Open on the
list of commands that pops up”. “Monitor > Module Details > Reciter”
means “click the Monitor icon on the toolbar, then in the navigation pane
find the Module Details group, and select Reciter from it”.
Please follow exactly any instruction that appears in the text as an ‘alert’.
An alert provides necessary safety information as well as instruction in the
proper use of the product. This manual uses the following types of alert:
This alert is used to warn about the risk of data loss or corruption.
This alert is used to highlight significant information that may be

required to ensure procedures are performed correctly, or draw your
attention to ways of doing things that can improve your efficiency or
effectiveness.
Associated Documents
The current set of product documentation is available on the Tait Partner
Portal website (https://partnerinfo.taitcommunications.com).
■ Tait Core Networks Installation and Configuration Manual
(MNB-00012-xx)
■ TN9271 Analog Gateway Installation and Operation Manual
(MNB-00017-xx)
■ TN8271 Network Gateway Installation and Operation Manual
(MNA-00028-xx)
■ TB9300 Base Station Installation and Operation Manual
(MBC-00008-xx)
(MBD-00001-xx)
10 Preface Tait TN9300 DMR Tier 3 Trunked System Manual

(MBC-00001-xx)
■ Dispatcher Interface Protocol Manual (MNA-00014-xx)
■ TN9300 DMR Channel Group System Manual (MNB-00010-xx)
■ Tait CMD Installation and Configuration Manual (MNB-00015-xx)
■ Tait CMD Operations Manual (MNB-00016-xx)
■ AIS Integration Guide (TD-0038-xx)
■ Telephony Integration Guide (TD-0040-xx)
■ DMR Data Integration Guide (TD-0044-xx)
■ Voice Recorder Protocol Integration Guide (TD-0053-xx)
Technical Notes are also published from time to time to describe

applications for Tait products, to provide technical details not included in
manuals, and to offer solutions for any problems that arise.
Acronyms and Definitions

4FSK Four level frequency shift keying. Constant envelope
modulation.
AAA Authentication, Authorization, Accounting - standard feature

of all new Tait networks offering centralized control for
network security
AES Advanced Encryption Standard
AIS Application Interface Support
ALS Ambient Listening Service
AMBE+2 Half-rate advanced multiband excitation vocoder
ANN Algorithmic Network Numbering - a numbering scheme used

to partition the MPT 1327 address space into more convenient
sub-sections for fleet management
API Application Programming Interface
ARC4 Alleged Rivest Cipher 4 - a simple encryption / decryption

algorithm. Currently considered as insecure.
BCAST Data messages intended for all radios listening to the trunking
site control channel
BOOTP Boot protocol - facilitates booting devices (clients) from a

network server rather than their local hard disks (such as
diskless workstations)
Tait TN9300 DMR Tier 3 Trunked System Manual Preface 11

CMD Control, Manage, Dispatch console
DES Data Encryption Standard
DHCP Dynamic Host Configuration Protocol - allows a host to

contact a central server which maintains a list of IP addresses
which may be assigned on one or more subnets
DIP Dispatcher Interface Protocol - used for making dispatcher-

like connections to a TaitNet node controller
DMR Digital Mobile Radio - an open radio standard
DSCP Differentiated Services Code-Point - a field in the IP header

that allows traffic to be classified for quality of service,
enhancing handling at each hop in a network. For example,
fast forwarding to reduce jitter or the probability of loss when
the network is congested.
FEC Forward Error Correction - a redundancy technique used to

detect a limited number of errors that may occur anywhere in
the data message transmission over unreliable or noisy
communication channels, and to correct these errors without
retransmission of the data message
FFSK Fast Frequency Shift Keying - the modulation used in MPT

1327 for sending control data
FGN Fleet Group Number (DMR standard numbering scheme

term)
FIN Fleet Individual Number (DMR standard numbering scheme

term)
FPP Fleet Partitioning Parameter - a parameter defined by the

ANN numbering scheme
FXO Foreign Exchange Office - the interface on a VoIP device for

connecting to a PSTN/PABX
GN Group Number (DMR standard numbering scheme term)
HA High Availability - critical elements can have a secondary unit

that takes over the operation if the primary unit fails
HTTP Hypertext Transfer (or Transport) Protocol - the data transfer

protocol used on the World Wide Web
ILOM Integrated Lights Out Manager - provides advanced service

processor hardware and software to manage and monitor Sun
servers

IN Individual Number (DMR standard numbering scheme term)
INI Inter-Node Interface
INP Inter-Network Protocol (TN9500 terminology)
IP Ingress Protection - a guide to indicate the sealing on an

enclosure for dust and water resistance, e.g. IP67 enclosure is
dust proof and water resistance to 1 meter for 1/2 hour
IP Internet Protocol
L0 The minimum signal level used attempting to acquire control

channel
L2 A signal level at or above which offers optimum service. In

Tait radios default -94 dBm.
LDT The T1542 Line Dispatcher Terminal, a common example of

Terminal Equipment (TE)
LIP Location Information Protocol
MAP27 Mobile Access Protocol for MPT 1327
MEP Miniaturization Extent Parameter - a parameter defined by the

ANN numbering scheme
MPT 1327 Industry standard for trunked radio communications networks
MPT 1343 The most frequently used numbering scheme to partition the
MPT 1327 address space into more convenient sub-sections
for fleet management
MS Mobile Subscriber - another term for radio user
MTBF Mean Time Between Failures
MTTR Mean Time To Repair
NAI Network Area Identity (DMR standard numbering scheme

term)
NP Number Prefix (DMR standard numbering scheme term)
OPUS Brand name of the interactive audio codec used to/from the
Tait AXIOM PTToX network
PABX Private Automated Branch Exchange
PDU Protocol Data Unit (i.e. a codeword)

PSTN Public Switched Telephone Network
QoS Quality of Service - a term which denotes the expected

performance of the system to the end user and the network
mechanisms used to increase the probability that the network
can meet the expectations under various loads
RAP Radio Access Protocol
RC Reverse channel. A signaling burst that can be sent in the

center of the adjacent time slot to radio units while they are
transmitting.
RCGA Radio Controlled Group Affiliation - the radio informs the

network which Talk Group it belongs to
RTP Real-time Transport Protocol - used in DIP version 3 for

transmitting/receiving voice data packets encoded using
G.711 μ-law
SDM Short Data Message - data sent on the control channel
SIP Session Initiation Protocol - a network communications

protocol commonly employed for Voice over IP (VoIP)
signaling
SGI Short Group Identity (DMR standard numbering scheme

term)
SNMP Simple Network Management Protocol - a standard TCP/IP

protocol for network management. Network administrators
use SNMP to monitor and map network availability,
performance, and error rates.
SSH Secure Shell - a remote login technology useful for making

command line connections between two computers
SSI Short Subscriber Identity (DMR standard numbering scheme

term)
TCP Transmission Control Protocol - a “send and acknowledge”

protocol for sending data packets over the internet. Each data
packet is acknowledged by the receiver, and is re-sent if it
does not arrive (or gets corrupted en-route). TCP favours
reliability over timeliness.
TE Terminal Equipment (typically a Radio or Line Dispatcher)
TS2 Digi 2 serial port server
TSCCAS Trunked Station Control Channel Alternate Slot - also known

as the alternate channel, being the logical channel
immediately adjacent to the control channel

USBD DMR Standards term meaning Unified Single Block Data - an
efficient way to transport data over the air
VoIP Voice over IP - a technology that allows telephone calls to be

made over computer networks like the Internet. VoIP converts
analog voice signals into digital data packets and supports
real-time, two-way transmission of conversations using
Internet Protocol (IP).
VPN Virtual Private Network - implements private networks over

public infrastructure
VRP Voice Recorder Protocol
Publication Record
Version Publication date Amended sections and pages
29 October 2022 Released for version 3.44 (TaitCentOS) and later, and version
4.44 (Tait Ubuntu) and later
■ Tait Ubuntu added throughout
■ Section 3.2.1 Tait TN9271 Analog Gateway and G.711
Connector updated
■ G.711/AIS-capable console systems added to Section 3.2.8
Interface Connectivity Options
■ Section 5.3.2 Obtaining the Host ID updated
■ Section 5.3.3 Obtaining the license.dat File updated
■ Section 6.2 Powering Down the Node Controller updated
■ Section 6.11.1 Version 4 (Tait Ubuntu) Firmware added
■ Section 7.2.2 Call Types updated
■ Section 7.2.3 Call End Reasons 121 added
■ Section 7.2.5 Call Handler IDs updated
■ Section 7.2.6 System IDs updated
■ Section 7.5 Monitoring Site Performance reference to html
reports removed
28 May 2022 Released for version 3.42 and later

■ General minor updates
■ ARC4 encryption added throughout
■ “DMR Full” on page 28 network dimension table updated
■ Section 3.2.2 Dispatch Equipment Tait CMD added
■ Section 3.1.10 Group Affiliation updated
■ Section 3.1.21 Encryption ARC4 added
■ Section 6.21.2 Upgrade Procedure command updated
■ Section 7.2.3 Call End Reasons 110, 713 and 900 added
■ Section 7.4.1 Site Statistics queue statistics (Q_) definitions
updated

27 December 2021 Released for version 3.40 and later

■ Sintrones SBOX-2621 replaces Sintrones SBOX-2620
■ TN9271 analog gateway and G.711 connector information
added throughout
■ “DMR Full” on page 28 dimension table updated
■ “DMR Express20” on page 29 dimension table updated
■ Section 2.7.1 Bandwidth Overview table updated
■ Section 2.7.8 Network Gateways updated
■ Section 2.8 IP Protocols and Ports table updated
■ Section 2.10.2 Bandwidth Considerations and
Recommendations table updated
■ Section 2.10.4 QoS/DSCP updated
■ Section 2.11 Audio Level Planning updated
■ Call queuing feature description updated in Section 3.1.4
Tait DMR System Features
■ Section 3.1.10 Group Affiliation updated
■ Section 3.2.1 Tait TN9271 Analog Gateway and G.711
Connector added
■ “Network Gateway VOX” updated
■ G.711 connector licenses added to Section 5.3.5 Licensed
Features
■ Section 6.8 Downloading General Statistics replaces
sections “Downloading Site Statistics” and “Downloading
Channel Statistics”
■ Section 6.13 Using Status Messages status message 123
added
■ Section 7.2.2 Call Types updated
■ Section 7.2.3 Call End Reasons updated; 646 to 649 and
800 to 801 added
■ Section 7.4 Monitoring Statistics updated

26 May 2021 Released for version 3.38 and later

■ Section 2.1 Network Dimensions updated
■ “DMR Express20” on page 29 updated
■ Section 2.7 IP Network Bandwidth general updates to all
bandwidth measurements
■ Section 2.14 Data Support updated
■ Channel authorization feature added, and USBD updated,
in Section 3.1.3 DMR Standard Features
■ Fast polling updated in Section 3.1.4 Tait DMR System
Features
■ Section 3.1.8 Channel Authorization added
■ Section 3.1.20 Background Checks added
■ Section 3.1.27 Fast Polling updated
■ Section 3.2.9 Console Connectivity Protocol Comparisons
updated
■ Section 5.18 Configuring Channel Authorization added
■ Section 7.3.2 Network Alarms 84 to 87 added
■ Section 7.2.1 Call Records File Format table updated
■ Table updated in Section 7.4.1 Site Statistics
25 December 2020 Released for version 3.36 and later

■ Footnote added to Section 2.7.8 Network Gateways
■ Section 3.1.29 Shared Channel Operation reference to
feature documentation added
■ Section 4.3.4 DMR Native Numbering Scheme updated
■ Section 5.5 Setting Up Users “Version 3.xxx and Version
4.xx” updated
■ Section 5.9.2 Adding Unit/Group Profiles and Service Areas
updated
■ Section 6.4.1 TaitCentOS/Tait Ubuntu - Administration
Application 1.16.01 and Later added
■ Section 6.16 Using Authentication Checking ‘Bar units that
fail check’ parameter replaced with ‘Reject requests that fail
authentication’ parameter
■ Section 6.18 Subscribing to Groups updated
■ Section 7.2.3 Call End Reasons 645 added, 612 updated
■ Section 7.2.6 System IDs table updated
24 August 2020 Released for version 3.34 and later
23 May 2020 Released for version 3.32 (and 2.32) and later
22 December 2019 Released for version 3.30 (and 2.30) and later
21 September 2019 Released for version 3.28 (and 2.28) and later
20 April 2019 Released for version 3.26 (and 2.36) and later
19 February 2019 Released for version 3.24 (and 2.24) and later
18 October 2018 Released for version 2.22, version 3.22 and later

17 May 2018 Released for version 2.20, version 3.02 and later
16 February 2018 Released for version 2.18, version 3.00 and later
15 September 2017 Released for 2.14 and later
14 April 2017 Released for 2.12 and later
13 January 2017 Released for 2.10 and later
12 July 2016 Released for 2.06 and later
10 January 2016 Released for 2.02 and later
8 November 2014 Released for 1.15 and later
7 August 2014 Released for 1.14 and later
6 May 2014 Released for 1.13 and later
5 December 2013 Released for 1.12 and later
4 August 2013 Released for 1.11 and later
3 May 2013 Released for 1.10 and later
2 February 2013 Released for 1.00 and later
1 October 2012 First release

1 Introduction
This section provides a general overview of the different DMR networks,

and gives an introduction to the principles and terminology of DMR
trunked (Tier 3) networks. DMR conventional (Tier 2) networks are
described in their own system manual.
1.1 DMR Networks Overview

DMR networks can be defined by a number of characteristics:
■ Network type (DMR conventional or trunked)
■ Channel type (single base station or channel group)
■ Transmit/receive (transceiver) or receive-only base stations
■ Simulcast or non-simulcast operation
All of the following DMR network types are available from Tait. In the
following diagram, the DMR trunked systems have been circled, as they
are the ones covered by this document:
DMR Conventional DMR Trunked

Receive only Transmit/Receive Receive only
Base station
Conventional Trunked
base station base station
Non-simulcast
Conventional non-simulcast
channel group
Channel group
(“voted channel”)
Simulcast
Conventional simulcast Trunked simulcast

channel group channel group
The following sections describe DMR trunked networks and their principal
concepts. DMR conventional networks are described in their own system
manual.
Tait TN9300 DMR Tier 3 Trunked System Manual Introduction 19

1.2 Network Principles
This section gives an introduction to the principal concepts of DMR
trunked networks.
At its most fundamental level, a DMR trunked Access network can consist
of between one and four base stations/repeaters, located at an appropriate
location to provide coverage, operating with a number of radios (see “DMR
Access” on page 30). The base stations contain an embedded basic
software node controller, as well as performing normal repeater functions.
DMR base station(s)
DMR mobile
radio(s)
DMR portable radio(s) DMR mobile radio(s)
More sophisticated networks can be created using multiple repeaters and

sites to provide wide area coverage. A basic Tait trunked DMR multi-site
network consists of a node (which controls the operation of the network)
and a number of sites, each of which consists of several base stations/
repeaters linked over an IP backbone network to form a wide area network.
SITE 1 IP interfaces to other

equipment
TB9300 base stations
TP9300 portable SITE 2

radios high availability nodes

TM9300 mobile
radios
SITE 3
interfaces to analog
equipment via TN9271
analog gateway
WAN
20 Introduction Tait TN9300 DMR Tier 3 Trunked System Manual

Tait DMR trunked networks support four different sized network types (see
Section 2.1 Network Dimensions):
■ Express6 - allows for a maximum of 6 sites
■ Express20 - allows for a maximum of 20 sites
■ Full - allows for the maximum possible capacity
■ Access - consists of 1 standalone site with no node controller
All of these network types: Express6, Express20 and Full, support fallback
mode in the case of failure. If a base station loses its connection to the node,
and is configured for fallback, it will try to contact all the other base
stations at the same site and will start working in single-site trunking mode
to allow local calls to proceed. The base station in fallback mode will
advertise its alarm state by transmitting a limited service indicator to radios
until the network is returned to its normal operating mode. The Access
network type is configured as a standalone site, not fallback.
The embedded basic software node controller in the base station (that
allows for fallback mode or standalone operations) does not perform
any of the following:
■ Radio unit validation

■ Traffic channel rotation
■ Inter-site calls (including to dispatch)
■ AVL messaging
Non-DMR base stations/repeaters (e.g. Analog, ActioNet, P25) can be

integrated into this network via one or more Tait gateways.
In a complex network, multiple nodes can be installed for high availability

and/or increased call capacity. The control node manages all aspects of the
network (including call priorities and rules) as well as switching of calls,
whereas additional switching nodes only switch calls. If the control node
fails, one of the switching nodes can take over as control node.
There are other important network elements such as timing units, gateways,
and the IP linking network with switches and routers, but for reasons of
simplicity these (as well as the node controllers) will only be shown and
described in detail as required.
Version 3 and Version 3.xx (TaitCentOS) and version 4.xx (Tait Ubuntu) DMR systems
Version 4 DMR consist of a number of software application modules that are supplied
systems
depending on the network type.
An administration application module is now always supplied and installed

as part of the TaitCentOS or Tait Ubuntu install package, and is used for
core network configuration and other network administrator tasks such as
setting up user accounts, firmware upgrades and backup/restore operations.
In addition to the administration application, DMR modules consist of the

controller application (trunked or conventional) and optional channel

group manager (for simulcast). Other applications are also available, such
as the DMR Trunked Data API Connector which is used in conjunction
with Tait Data API to integrate data from the DMR trunked network into
other applications, as required.
1.2.1 RF Channels and Logical Channels

On an analog network, the transmit and receive RF channels of a base
station transceiver can be programmed for a specific pair of RF
frequencies. In this case, there is one logical channel for each RF channel.
On a DMR network, a single RF channel has two logical channels, thereby

doubling the call capacity.
Figure 1.1 Logical channels
Tx1 Rx1 Tx1 Rx1
Logical channel 1
Logical channel 1
Logical channel 2
Analog base station DMR base station
DMR systems use digital modulation and 2-slot TDMA (time division
multiple access) on the RF path between the base stations and the mobile
radios. TDMA divides up the frequency spectrum using time slots whereby
user A gets a few milliseconds of access to the spectrum, then it’s the turn
of user B so that one physical channel (transceiver) provides two “logical”
channels on each 12.5 kHz bandwidth transmit and receive frequency (one
on each time slot).
The pair of RF frequencies for the two logical channels is the same.
1.2.2 Control Channels, Traffic Channels and Alternate Channels
The logical channels may be separated into three categories:

■ Control channel
■ Traffic channel (or payload channel)
■ Alternate channel
The control channel is used to provide signaling to the radio units.

The signaling to the radios has multiple purposes, such as system
identification and processing of call requests.
The traffic channel is used to provide a communications path for many call
types, i.e. speech or packet data calls.

The second logical channel located on the base station with the control
channel can be configured to be used as an alternate (or fast polling)
channel. The alternate channel can, for example, be used to declutter the
control channel from regular polling data responses from the radio units.
At each site, there can be up to two control channels, a number of traffic

channels, and a maximum of one optional alternate channel. Multiple
control channels are used if there are a large number of radios using the site
or if there is a lot of data traffic (e.g. the Short Data Service (SDS) or GPS
location data) on the control channel. An alternative to multiple control
channels is to enable one control channel to have an alternate channel. The
radio configuration allows or restricts access to specific control channels.
Two control channels can be on the same base station (using both logical
channels) or on different base stations (using one logical channel from
each). Whether a logical channel operates as a control channel, alternate
channel, or a traffic channel is determined by the node and can be
configured to meet your organizational requirements.
The use of alternate channels is only supported by DMR networks run-

ning firmware (3.26 or 2.26 and later) that is compliant with DMR spec-
ification TS 102 361-4 DMR Trunking Protocol 1.9.2 or later.
1.2.3 Physical Sites and Functional Sites

A physical site is a location where network equipment (including base
stations) is installed.
A functional site represents a contiguous area of coverage, and is

represented by a set of frequencies dedicated to that site.
In a non-simulcast network, channel groups are not required, and all the
channels at one physical site form one functional site.
In a simulcast channel group, all the channels at all physical sites form one
functional site.
The following example shows a network with three functional sites (two
non-simulcast and one simulcast), made up of five physical sites.

Figure 1.2 Physical sites and functional sites (example)
Physical site 1 Physical site 2 Physical site 3 Physical site 4 Physical site 5
Tx1 Tx3 Tx5 Tx5 Tx5

Rx1 Rx3 Rx5 Rx5 Rx5
Channel 1, Site 1 Channel 1, Site 2 Channel group 1
Tx2 Tx4 Tx6 Tx6 Tx6

Rx2 Rx4 Rx6 Rx6 Rx6
Channel 2, Site 1 Channel 2, Site 2 Channel group 2
The grey frames show two functional sites (with two channels each) at
physical sites 1 and 2. Note that all the frequency pairs of the base stations
are different (Tx1/Rx1 to Tx4/Rx4).
The blue frame shows a simulcast functional site (with two channel groups)
at physical sites 3,4 and 5. Note that all the frequency pairs within each
channel group are the same (Tx5/Rx5 and Tx6/Rx6 respectively),
identifying it as a two-channel simulcast network.
Functional sites are configured in the node controller. If the physical sites
need to be defined (as the functional sites may contain more than one
physical site), this also needs to be defined in the node controller. If the
network has functional sites that consist of more than one physical site,
then configuration is also required in the Channel Group Manager
application.
1.2.4 Single Channel Base Station

In single channel base station operation, as opposed to simulcast, a
functional site is the same as a physical site.
In single channel base station operation, calls take place on only the
channels required for the call.
1.2.5 Simulcast Channel Groups

Simulcast channel groups are useful where large coverage but limited
traffic is required.
Channel groups are defined as base stations

■ On multiple physical sites
■ Forming a single functional site
■ Using the same logical channel
■ Carrying the same information on the downlink

A channel group carries the same information within a single functional
site.
In a channel group, one of the base stations has the role of central voter
(also referred to as “master base station” elsewhere); the other base stations
are called satellites. The central voter represents the functional site of all
base stations in the channel group. The logical channels of the satellites are
the same as the central voter.
The base stations of a channel group transmit and receive using the same
transmit and receive frequency pair (simulcast).
The RF signals received from all base stations of a channel group are sent
to the central voter via the IP network. The central voter breaks down the
streams into segments, decides on the best signal for each segment,
reconstructs the stream using these best segments, and sends the
reconstructed stream to the control or switching node.
The control or switching node sends the call to the central voter to be re-
transmitted simultaneously by the central voter and all satellites taking into
account IP delays and geographical conditions.
A timing unit at each physical site provides the necessary synchronization.
Channel groups are configured in the base stations and the node controller.
Channel groups are described in detail in the TN9300 DMR Channel

Group System Manual (MNB-00010-xx).

2 Network Design
There are several issues that need to be taken into account when planning
a DMR trunked radio network. The areas to consider during this initial
planning phase are as follows:
■ Network Dimensions
■ Server Information
■ Channel Spacing
■ Frequency Bands
■ Power Supply
■ Base Station Comparisons
■ IP Network Bandwidth
■ IP Protocols and Ports
■ IP Address Planning
■ Network Linking Design
■ Audio Level Planning
■ Redundancy and High Availability
■ Speech Call Capacity
■ Data Support
■ Packet Data Transfer Times
■ Network Time Protocol
■ Centralized Authentication
26 Network Design Tait TN9300 DMR Tier 3 Trunked System Manual

2.1 Network Dimensions
There are three levels, or tiers, of server used in DMR networks that should
be selected depending on network size:
Level Server Operating System
High Sun Netra X3-2 Unix - Solaris 10
Sun Netra X4200/X4250/

X4270
Kontron CG2300 Linux - TaitCentOS or

Tait Ubuntu
Kontron CG2400
Mid Dell R250
Dell R240
Dell R230
Dell R220
Low Aleutia R50
Sintrones SBOX-2620
Sintrones SBOX-2621a
a. 560-00006-xx is the DIN rail mounting kit associated with this server
Note that the shaded areas denote equipment that has reached end-of-life
(by the manufacturer or by Tait), and whilst currently supported, is no
longer available.
The following dimension information does not include limits and

capacities for networks with simulcast channels. Refer instead to the
Channel Group Manager System Manual.
It is recommended that networks using simulcast or the DMR Trunked

Data API Connector have all the node controllers running either version
3 or version 4 only. A network with either version 3 or version 4 node
controllers with a channel group manager (for simulcast) and high avail-
ability in particular cannot operate with version 2 node controllers.
It is important to note that the maximum dimensions listed below are for
individual DMR networks of each license type. Where larger systems are
required, a TN9500 Inter-network Gateway can be used to connect
individual DMR networks together to create a system of multiple networks
communicating together over a large coverage area.
Tait TN9300 DMR Tier 3 Trunked System Manual Network Design 27

DMR Full The following table gives the maximum dimensions of a DMR Full
network.
Limits for high Limits for mid tier Limits for low tier
Element
tier servers servers servers
Sites/network 250 100 20
Control channels/network 250 100 20
Physical channels/network 1000 (2000 logical 250 (500 logical 80

channels) channels)
Physical channels/site 20 (40 logical channels)
Physical channels/fallback site 20 (40 logical channels)
Nodes/network 20
Active audio connections/nodea 250 100

(Active connections consist of:
■ reciter logical channels
■ network gateways
■ a call on an AIS trunk
■ a call on an SIP trunk
■ a call on an INP trunk
■ voice recorders)
Network gateways/networkb 300 150 24
Physical DIP connectionsb 300c 150c 24
Physical SIP and AIS connectionsbd 300c 150c 24
Concurrent packet data calls to packet 200 50 24

data gateway/Network (single slot only)
Concurrent encrypted voice callse 24f

(ARC4/DES/AES)
High Availabilityb Yes
Inter-network connections/networkg 1
Tait TeamPTT connections/network 1
G.711 connectors/network
■ co-located on TN9300 server 6 per server
■ co-located on TN9500 server 100 per server
TN9271 analog gateways/network 300 150 24
a. Audio connections refer to all RTP links.

b. These features require separate licenses, refer to Section 5.3.5 Licensed Features.
c. DIP, AIS, SIP and INP connections are to the control node. These figures are achieved only in multi-node sys-
tems. Each high tier switching node can handle up to 250 active audio connections. Each mid tier switching
node can handle up to 100 active audio connections. Adding more nodes, gives you more calls. The maximum
number of calls supported on a DMR network is 1000.
d. Peak load only.
e. Involving external interfaces (where the controller needs to encrypt/decrypt voice calls).

f. This value is per controller. If the network has more than one controller and a switching node is switching calls,
it can also encrypt/decrypt 24 encrypted calls for the external interfaces. The node will not fail new encrypted
calls that exceed the 24 call limit; they will be accepted, however voice quality will be negatively impacted.
g. This corresponds to the number of inter-network connections supported by the network. Currently the interface
is for connecting to a TN9500 Inter-Network Gateway that can connect up to 9 networks together (see TN9500
documentation for limits and more information).
The DMR high tier node supports 200 concurrent data calls. This means
200 single slot concurrent data calls, or 100 concurrent dual slot data
calls.
Where smaller networks are required, the DMR Express20, DMR Express6
and DMR Access licensed networks are available as follows:
DMR Express20 DMR Express20 has the following maximum dimensions, and requires
Express20 licenses for the node and reciters:
Limits for high/mid/low tier

Element
servers
Sites/network 20
Control channels/network 20
Physical channels/network 80 (160 logical channels)
Nodes/network 20
Physical DIP connections 24
Concurrent SIP (phone) calls/network 24
Concurrent AIS (external equipment) 24

calls/network
Concurrent packet data calls to packet 24

data gateway/network (single slot only)
Inter-network connections/networka 1
a. This corresponds to the number of inter-network connections supported by the

network. Currently the interface is for connecting to a TN9500 gateway that
can connect to many networks (see TN9500 documentation for limits and
more information).
Licenses for network interfaces and High Availability must be obtained

separately, see Section 5.3.5 Licensed Features.

DMR Express6 DMR Express6 has the following maximum dimensions, and requires
Express6 licenses for the node and reciters:
Limits for high/mid/low tier

Element
servers
Sites/network 6
Nodes/network 1
Physical DIP connections 24
Concurrent SIP (phone) calls/network 24
Concurrent AIS (external equipment) 24

calls/network
Concurrent packet data calls to packet 24

data gateway/network (single slot only)
Inter-network connections/networka 1
a. This corresponds to the number of inter-network connections supported by the

network. Currently the interface is for connecting to a TN9500 gateway that
can connect to many networks (see TN9500 documentation for limits and
more information).
Licenses for network interfaces must be obtained separately, see

Section 5.3.5 Licensed Features.
DMR Access DMR Access is for single site systems that do not require a node controller
as such, and has the following maximum dimensions. Access licenses are
installed in the reciters:
Element Limits
Sites/network 1
Nodes/network Standalonea
a. A standalone node is a logical function in a reciter. It enables single site trunk-

ing operation.
As DMR Access does not have a node controller, some external interfaces
such as AIS, DIP and Voice Recorder connections are not supported.

2.2 Server Information
Server Management
Server AC DC
Port
Kontron CG2400 100VAC to 240VAC -40VDC to -75VDC BMC

(dual power supplies) (dual power supplies)
Idle current = 96W Power up maximum

current = 5.8A at -48V
100% CPU load = 132W (278W)
Idle current =
2.1A at -48V (101W)
100% CPU load =

2.5A at -48V (120W)
Dell R250 100VAC to 240VAC input iDrac
250W maximum
Sintrones SBOX- N/A 9VDC to 36VDC input Not available

2621
12W nominal, 30W peak
2.3 Channel Spacing

DMR channel spacing is 12.5 kHz. (This is not always the case, they can
be issued at 25 kHz, if required.)
2.4 Frequency Bands
2.4.1 TB7300
The TB7300 base station is available in the following frequency bands and
power:
Frequency
Frequency Band and Sub-band 40 W 50 W
Identification
B band B1 = 136 MHz to 174 MHz No Yes
H band H3 = 470 MHz to 520 MHz Yes No

H5 = 400 MHz to 470 MHz Yes No
For TB7300 transportable base station frequency bands, please contact

Tait.

2.4.2 TB9300
power:
Frequency
50 W 100 W
Identification Frequency Band and Sub-band
B band B2 = 136 MHz to 156 MHz Yes Yes

B3 = 148 MHz to 174 MHz Yes Yes
C band C1 = 174 MHz to 193 MHz Yes No

C3 = 216 MHz to 225 MHz No Yes
G band G4 = 330 MHz to 380 MHz Yes No
H band H1 = 400 MHz to 440 MHz Yes Yes

H2 = 440 MHz to 480 MHz Yes Yes
H3 = 470MHz to 520 MHz Yes Yes
H4 = 380MHz to 420 MHz Yes Yes
H5 = 400MHz to 470MHz Yes No
HC = 400 MHz to 440 MHz (receive) Yes No

HC = 440 MHz to 480 MHz (transmit) Yes No
K band K4 = 792 MHz to 824 MHz (receive) Yes Yes

K4 = 762 MHz to 776 MHz (transmit) Yes Yes
K4 = 850 MHz to 870 MHz (transmit) Yes Yes
K8 = 787 MHz to 788 MHz (receive) No Yes
K8 = 757 MHz to 758 MHz (transmit) No Yes
L band L2 = 896 MHz to 902 MHz (receive) No Yes

L2 = 927 MHz to 941 MHz (transmit) No Yes
2.4.3 TB9400
power:
Frequency
Frequency Band and Sub-band 50 W 100 W
Identification
B band B3 = 148 MHz to 174 MHz Yes Yes
H band H1 = 400 MHz to 440 MHz Yes Yes

H2 = 440 MHz to 480 MHz Yes Yes
2.5 Power Supply

The nature of the power supply provided at each node and site will dictate
the power equipment needed by the system. The various DMR network
elements support one or more of the following options:
■ 110 V AC mains power
■ 240 V AC mains power
■ 12 V DC

■ 24 V DC
■ 48 V DC
2.6 Base Station Comparisons

The following table serves to compare the TB7300, TB9300 and TB9400
base stations.
TB7300 TB9300 TB9400
Operating modes Analog conventional Analog conventional Analog conventional

DMR conventional DMR conventional DMR conventional
DMR trunked DMR trunked DMR trunked
MPT-IP analog trunked MPT-IP analog trunked MPT-IP analog trunked
P25 P25
AS-IP AS-IP
Output power Depends on frequency 50 W or 100 W

band (see Section 2.4.3
TB9400)
Minimum output 1 W - depends on frequency 5 W (50 W PA)

power band 10 W (100 W PA)
Power options 14 VDC 120 VAC

230 VAC
12 VDC
24 VDC
48 VDC
Frequency bands See Section 2.4 Frequency Bands
Rack height 1Ua 4U with PMU
Weight 6.7 kg (14.8 lb) 21.5 to 22.8 kg 16.9 kg to 24.8 kg

(47.4 lb to 50.3 lb) (37.3 lb to 54.7 lb)
depending on product depending on product
options options
Operating -30o C to +60o C (-22o F to +140o F) ambient temperature

temperatures (the temperature of the air at the intake to the cooling fans)
Maximum capacity 1 Tx/Rx 2 x 50 W or 1 x 100 W
Rx only Firmware only Firmware only - does not Hardware and firmware
affect maximum capacity options
Use ■ Space restricted sites Multi-channels or sites with high coverage

■ Low traffic capacity sites
■ Sites requiring lower
power consumption
■ Infill sites requiring
lower RF power
Simulcast/voting Yes - all base stations are interoperable
a. The TB7300 base station is also available in a transportable variant in a Pelican case. The TB730x is the DMR
conventional transportable default package, and licenses are available for use in DMR trunked networks (see
Section 5.3.5 Licensed Features). Contact Tait for more information.

2.7 IP Network Bandwidth
2.7.1 Bandwidth Overview
All DMR networks have a single designated control node. All other nodes
on the network are designated as switching nodes. Control traffic on the
network originates or terminates at the control node. In contrast, voice
traffic is switched by any one of the nodes on the network.
The control node is selected from any of the available nodes. The selection
algorithm is weighted so that the node with the lowest priority number will
be the control node. If the lowest priority number node should fail, then the
next lowest priority number node will become the control node.
The control node establishes connections to the base stations and network
gateways. The protocols used are UDP based, using ports 10001 to 10250
for base stations, and 9006 for network gateways1. The dispatch console
system establishes connections to the current control node using a TCP
based protocol on port 9005, or SIP on port 5060. For a full list of IP port
usage, go to “IP Protocols and Ports” on page 40.
The nodes maintain TCP connections to each other so that they can share
database updates and status. The bandwidth used by this link is normally
less than 100 kbit/sec, although this is dependent on system size (primarily
the number of radios on the system). Most of the traffic is from the control
node to the switching nodes and it is not necessary to scale the link
bandwidth when the number of nodes is increased.
The following table gives a summary of the approximate maximum

bandwidth required.
Approximate Maximum Bandwidth

Type
(inbound or outbound)
Control channel 11 kbits/sec @ 16 packets/sec
Loaded alternate channel 10 kbits/sec @ 17 packets/sec
Idle traffic channel 1 kbits/sec @ 2 packets/sec
Active traffic channel 15 kbits/sec @ 18 packets/sec
Idle TN8271/G.711 connector (per 1 kbits/sec @ 2 packets/sec

instance)
Active TN8271/G.711 connector 110 kbits/sec @ 52 packets/sec (G.711)

transcoding between AMBE and G.711 18 kbits/sec @ 18 packets/sec (AMBE)
Active TN8271 network gateway 22 kbits/sec @ 18 packets/sec

transcoding between AMBE and analog
1. Note that when a TN8271 network gateway is used for transcoding AMBE
to/from G.711, the network gateway uses port 9052 for the G.711 stream.

Approximate Maximum Bandwidth
Type
(inbound or outbound)
TN9271 analog gateway in active call 110 kbits/sec @ 52 packets/sec (G.711)

with G.711 connector
Active TN9500 inter-network gateway 42 kbits/sec @ 51 packets/sec (OPUS)

transcoding between DMR and Tait 20 kbits/sec @ 20 packets/sec (AMBE)
AXIOM PTToX
Active SIP gateway/router per G.711 95 kbits/sec @ 51 packets/sec

stream
AIS connection with AMBE 17 kbits/sec @ 18 packets/sec
AIS connection with G.711 105 kbits/sec @ 53 packets/sec
INP connection with AMBE 25 kbits/sec @ 34 packets/sec
SNMP per channel Varies depending on:

■ Number of devices
SNMP per node controller
■ Polling period in minutes
■ Number of monitoring parameters
per device
■ Period of traps
LIP per subscriber 1 kbit/sec @ 0.01 packets/sec
DMR HA connection at control node 350 kbits/sec @ 300 packets/sec

(measured with 1500 units and AVL
polling)
DMR HA connection at switching node 320 kbits/sec @ 300 packets/sec

(measured with 1500 units and AVL
polling)

2.7.2 IP Bandwidth Data Flows
The following information does not apply to simulcast systems.
The following diagram shows the voice/packet data flow with no control
plane.
For each call (voice or packet data)

Console 2 – unicast *
* may need to go
through the control
node if the AIS
interface is only on
the control node
Control node Switching node

1 - unicast
Using the least

busy node
2 – unicast
Call
The IP bandwidth allocation needs to take into account the number of base
stations and logical channels supported.
If the call is generated from the console instead of a radio, the flow is
similar. It is important to assign enough bandwidth for each of the nodes,
not only the control node.
The following diagram shows IP data flow:

For each IP data call
Console
Router with
2 – unicast mobile IP
Control node Switching node
1 - unicast
IP data
packets
External application collecting

IP data packets from the end
points (the radios, in this case)

IP bandwidth for the control node is critical for IP data, as all packets are
sent to the control node and then to the mobile IP router.
Note that this scenario assumes that the IP data packets are not being sent
to other LMR equipment (i.e. other radios – as that is not the recommended
use of IP data).
2.7.3 Voice Switching
The following information does not apply to simulcast systems.
Voice call requests are received by the control node from base stations,
dispatch console systems, and also from DIP, SIP, INP or legacy radio
network connections. On receipt by the control node, if the call request is
valid, the destination party or parties are available, and there is sufficient
resource (traffic channels, network gateways and switching nodes) to carry
the call, the call will be assigned to one of the switching nodes. The
resources required for the call are instructed to send and receive voice via
this switching node for the duration of the call. All voice traffic will be
switched directly through this node but control traffic will be switched
through the control node.
The control node will allocate a call to the switching node that is least
loaded. The control node is also treated as a switch in addition to its control
functions; it will be assigned to switch calls too.
It is possible to exclude one or more nodes from the list of switching nodes
that calls are assigned to by allocating a switching zone. If this is enabled
then voice packets will only be switched between nodes in the same
switching zone.
The switching zone feature allows nodes to be grouped so that particular

nodes can be excluded from switching audio. In some networks, a node
may be installed in a geographic region where the bandwidth to this region
from the rest of the network is limited. The node is installed in this region
so that if the network link to the rest of the network breaks, the node will
enter control mode and provide service to the sites in this region. However,
standard network design means that nodes in these isolated regions will
switch audio for any site in the network, but this is not desirable because
this could saturate the network links to the region.
2.7.4 Packet Flows
For traffic to and from each node, the expected traffic depends on the
number of nodes, number of network gateways and base stations. The
maximum number of devices a node can concurrently switch is 250, which
is approximately 4 Mbit/sec. This represents the absolute upper limit of
traffic to a node.
A basic estimate of bandwidth required for each node is: (bandwidth used
by dispatch system + bandwidth used by site) / (number of nodes available

- 1). We allow for the failure of a single node in this model. For a system
consisting of 150 logical channels, 75 dispatch talkgroups (AMBE) and 4
nodes (of which we assume one has failed putting more traffic on the
others), this would require 1.5 Mbit/sec to each node.
For simulcast bandwidth estimations, please refer to the TN9300 DMR

Channel Group System Manual (MNB-00010-xx).
2.7.5 Maintenance Traffic
For every site, we recommend that at least 100 kbit/sec is provided to allow
for the operation and collection of diagnostics using http or SNMP. As
using http cannot monitor many base stations simultaneously, it is not
normally necessary to provide the 100 kbit/sec to all sites at the same time.
It is acceptable to make a smaller bandwidth allowance on the backbone.
For every node, we recommend an absolute minimum of 100 kbit/sec for

maintenance operations but we prefer 1000 kbit/sec or more if possible.
2.7.6 Node Controller
Each node controller needs sufficient bandwidth to receive voice streams

of up to the number of channels and network gateways, or a maximum of
250.
2.7.7 Base Stations
The bandwidth used by each channel of a base station varies depending on

the operating mode of the channel. (This does not apply to simulcast
networks. Please refer to the TN9300 DMR Channel Group System
Manual (MNB-00010-xx).)
A control channel uses:

■ 5 kbits/sec @ 10 packets/sec
A loaded alternate channel uses:

An idle traffic channel uses:

■ 1 kbit/sec @ ~2 packets/sec
A traffic channel with voice being repeated uses:

For site planning purposes, the recommendation is to allow 64 kbits/sec per

physical channel. This will provide sufficient bandwidth to cater for any
additional diagnostics and maintenance that might be required.

2.7.8 Network Gateways
In the same way as the base stations, the bandwidth used by each network
gateway varies depending on the operating mode. Network gateways
(TN9271 analog gateway, G.711 connector, TN8271 network gateway)
process one call at a time.
An idle network gateway (maintenance traffic) uses:

■ 2 kbit/sec @ 1 packets/sec
An active network gateway (TN8271 network gateway or G.711 connector)

transcoding between AMBE and G.711 uses:
■ G.711 stream: 103 kbits/sec @ 52 packets/sec2
■ AMBE stream: 16 kbits/sec @ 17 packets/sec

transcoding between DMR and Tait AXIOM PTToX uses:
■ 41 kbits/sec @ 51 packets/sec (OPUS)
■ 18 kbits/sec @ 18 packets/sec (AMBE)

transcoding between AMBE and analog uses:
The TN9271 analog gateway requires 110 kbits/sec @ 52 packets/sec.
2.7.9 Telephony Gateways
A single SIP interface uses:

Tait recommends that a minimum of 320 kbits/sec be provided to support

each gateway, regardless of the number of interfaces actually used, thus
allowing for future expansion.
2. Note that when a TN8271 network gateway is used for transcoding AMBE
to/from G.711, the network gateway uses port 9052 for the G.711 stream.

2.8 IP Protocols and Ports
The network uses a variety of IP based protocols between its elements. In
some situations firewalls must be configured to allow this traffic to pass
across the IP bearer network. (For the additional protocols used in
simulcast networks, please refer to the TN9300 DMR Channel Group
System Manual (MNB-00010-xx).)
Notice Gratuitous ARP must be supported by the LAN for the high
availability feature in node controllers to work.
The following table lists the ports and their usage.
Where the port number could be in the range 3276 to 65535 (depending
on the Solaris/Linux/Windows ephemeral port range), it is listed as
‘UDP varies’ or ‘TCP varies’.
Destination Ports/
Source Ports
Type Usage Protocols
(on node)
(on remote device)
Core Interfaces
■ Voice data protocol Node controllers to/from UDP 9050 UDP 9050
(VDP) base stations and
network gateways, also
between control and
switching nodes for
packet data
Node controllers to/from UDP 9050 41398 + (4 * connection

G.711 connector index)
■ Base station protocol Node controllers to/from UDP 10000 + site_ID UDP 9017, UDP11000 +
(BSP) base stations and Channel_Group_IDa
channel group managers
■ Channel group status Node controllers to/from UDP 9018 UDP 9018
protocol (SVP) base stations
■ Channel group voice Base stations to/from UDP 27260 UDP 27260
protocol (CGP) base stations
■ Network gateway Node controllers to/from UDP 9006 UDP 9006

protocol (NGP) network gateways
Node controllers to/from UDP 9006 UDP 9026

G.711 connector
■ Node to node Node controllers to/from TCP varies TCP 9060

communications (INI) node controllers
■ InterNetwork Protocol Node controllers to/from UDP/TCP 5060 UDP/TCP 5060

(INP) the TN9500

Destination Ports/
Source Ports
(on node)
(on remote device)
■ RADIUS RADIUS authentication UDP varies UDP 1812, 1813, 1645

authentication server to/from node and 1646
controllers, switches,
base stations, network
gateways and routers
■ LDAP authentication LDAP authentication TCP varies TCP 389 and 636
server to/from node
Interfaces to consoles, AVL and data applications
■ Mobile IP Cisco home agent router UDP 9070 UDP 434 and IP over IP
to node controllers
■ Location information AVL system to Cisco UDP 11433 UDP 11433

protocol (LIP) home agent/radio IPs
■ Dispatcher Dispatch systems to TCP 9005 TCP varies

information protocol node controllers
(DIP)
■ Dispatcher Dispatch monitor to node TCP 9013 TCP varies

information protocol controllers
(DIP) - DIP monitor
■ Application interface Dispatch systems to/from UDP/TCP 5060 UDP/TCP 5060

specification (AIS) node controllers
■ TeamPTT TeamPTT to/from node UDP/TCP 5062 UDP/TCP 5062

controller
■ Session initiation Telephony/PABX to/from UDP/TCP 5060 UDP/TCP 5060

protocol (SIP) node controllers
■ Real time protocol Dispatch systems or UDP varies UDP varies

(RTP) TN9500 to/from node
controllers
■ Voice recorder Audio to media recorders UDP 9050 UDP 9999

protocol (VRP)
Management interfaces
■ Web interface (https) Management PC to node TCP 443 TCP varies

controllers, base
stations, NMS, switches
and routers
■ Secure shell (ssh) Node controllers, TCP 22 TCP varies

network gateways, base
stations, switches and
routers to NMS
■ Network time protocol Node controllers, UDP 123 UDP 123

(NTP) network gateways, base
routers to NMS

Destination Ports/
Source Ports
(on node)
(on remote device)
■ Syslog Node controllers, UDP varies UDP 514

routers to NMS
■ Simple network NMS to node controllers, UDP 161 UDP varies

management protocol network gateways, base
(SNMP) stations, switches and
routers
■ Simple network NMS to node controllers, UDP varies UDP 162

(SNMP) - Traps stations, switches and
routers
■ ICMP NMS and management ICMP ICMP

PC to node controllers,
routers
■ RDP SNMP Manager Remote TCP 3389 TCP 3389

Desktop. (Not required
but preferred for VPN
access if EnableMonitor
is deployed.)
■ Data API Connector Data API Connector to UDP 80 UDP 80

port Data API, node
controllers
a. For channel group managers, this is the port on which the channel group manager will listen for
messages from the TN9300 node controller.
You will need to make sure this port matches on both the node controller and channel group man-
ager. This can be found by logging into the node controller and navigating to the corresponding
site. From there select the channels tab. This tab lists the logical channels on the site. The logical
channels that represent channel groups will have an IP address of 127.0.0.1. Select the appropri-
ate channel and click View. On the next page there will be a field labelled IP address. This will con-
sist of an IP address and a port number, e.g.127.0.0.1:11001
In this example, the port number is 11001. For correct operation, the Simulcast/Voting > BS Chan-
nel Groups > Viewing and Editing a Base Station Channel Group's Configuration > Controller Port
field value in the channel group manager application must match. Tait recommends using port
11000 + channel group ID.
If you cannot find a corresponding logical channel on the node controller you will need to add one
and ensure that the Port field on the node controller matches this field.

Destination Ports/
Source Ports
(on node)
(on remote device)
Core Interfaces
■ Voice data protocol Node controllers to/from UDP 9050 UDP 9050
(VDP) base stations and
network gateways, also
between control and
switching nodes for
packet data
■ Base station protocol Node controllers to/from UDP 10000 + site_ID UDP 9017
(BSP) base stations
■ Channel group status Node controllers to/from UDP 9018 UDP 9018
protocol (SVP) base stations
■ Channel group voice Base stations to/from UDP 27260 UDP 27260
protocol (CGP) base stations
■ Network gateway Node controllers to/from UDP 9006 UDP 9006

protocol (NGP) network gateways
■ Node to node Node controllers to/from TCP varies TCP 9060

communications (INI) node controllers
■ RADIUS RADIUS authentication UDP varies UDP 1812, 1813, 1645

authentication server to/from node and 1646
■ LDAP authentication LDAP authentication TCP varies TCP 389 and 636
server to/from node
Interfaces to consoles, AVL and data applications
■ Mobile IP Cisco home agent router UDP 9070 UDP 434 and IP over IP
to node controllers
■ Location information AVL system to Cisco UDP 11433 UDP 11433

protocol (LIP) home agent/radio IPs
■ Application interface Dispatch systems to/from UDP/TCP 5060 UDP/TCP 5060

specification (AIS) node controllers
■ Session initiation Telephony/PABX to/from UDP/TCP 5060 UDP/TCP 5060

protocol (SIP) node controllers
■ Real time protocol Dispatch systems to/from UDP varies UDP varies
(RTP) node controllers
Management interfaces
■ Web interface (https) Management PC to node TCP 443 TCP varies

controllers, base
stations, NMS, switches
and routers

Destination Ports/
Source Ports
(on node)
(on remote device)
■ Secure shell (ssh) Node controllers, TCP 22 TCP varies

routers to NMS
■ Network time protocol Node controllers, UDP 123 UDP 123

(NTP) network gateways, base
routers to NMS
■ Syslog Node controllers, UDP varies UDP 514

routers to NMS
■ Simple network NMS to node controllers, UDP 161 UDP varies

(SNMP) stations, switches and
routers
■ Simple network NMS to node controllers, UDP varies UDP 162

(SNMP) - Traps stations, switches and
routers
■ ICMP NMS and management ICMP ICMP

PC to node controllers,
routers
■ RDP SNMP Manager Remote TCP 3389 TCP 3389

Desktop.
2.8.1 Additional Port Usage Information
The ephemeral ports used by the base stations are in the range of 12500 to
14999 (inclusive).
They are all UDP ports which are configured via the base station WebUI
for communicating with the node controller, or within a channel group
when operating as a DMR base station.
These can be configured on the following base station WebUI pages when
the DMR software is running:
1. Configure > DMR Network:

■ Control port: Default value: 9017. Used for DMR-related control
communications (BSP protocol) with the node controller or
standalone node.
■ Traffic port: Default value: 9050. Used for DMR-related voice
and data communications (VDP protocol) with the node
controller or standalone node

■ Status port: Default value: 9018. Used for status update related
communications (SVP protocol) with the DMR channel group
manager.
■ Multicast discovery port: Default value: 9218. Used for
discovering other base stations at the site in DMR fallback mode.
■ Standalone node control port: Default value: 9217. Used in
Embedded Node Controller Application for DMR-related control
communications (BSP protocol) with the base station
application.
2. Configure > Channel group:

■ Port: Default value: 27260. Used for voice and data
communications (RTP) within the base station channel group.
■ Port +1 (i.e. by default 27261) is used for control
communications (RTCP) within the base station channel group

2.9 IP Address Planning
2.9.1 Structure
This section describes the Tait IP address plan for DMR systems. (This
standard address plan does not cater for simulcast networks. Please refer to
the TN9300 DMR Channel Group System Manual (MNB-00010-xx).)
The network operates only on IP version 4. If the IP backbone supports

only IP version 6, then traffic for the network must be tunnelled.
There are no particular restrictions on the selection of the IP addresses,

however, the assignment of IP addresses using DHCP and BOOTP is not
supported.
All elements of the network require one IP address with the following
exceptions:
■ A virtual IP address is required for the node controller currently in
control mode. This IP address will move to whichever node controller
is operating in control mode. The use of the virtual IP address is not
required by all networks.
■ A second IP address is required for each node controller’s ILOM
(Oracle), BMC (Kontron) or iDRAC (DELL) console, depending on
server type
2.9.2 Standard Address Plan
Tait builds its DMR systems with the private class B network 172.29.0.0
(mask 255.255.0.0), unless a customer has other requirements. The class B
block is split into ranges based on the third number of the IP address.
All node equipment is assigned to the range 172.29.0.x. This is sufficient

for the needs of most systems, except for systems with more than 75
dispatch consoles, which would require a customized scheme.
Host IP Description
Default Router 172.29.0.254 This is the default router for all

equipment on this network
Active Node IP 172.29.0.1 The IP address of the control node
Switch 1 to 9 172.29.0.10 + <Switch The IP address of any switches that

ID> are required in this range, e.g.
Switch 1 has an IP address of
172.29.0.11
Consoles, 172.29.0.20 + <equipment The IP address of any equipment

Voice ID> required in this range, e.g. the first
Recorders and element has an IP address of
NMTs 172.29.0.21

Host IP Description
Node 1 to 20 172.29.0.100 + <Node The IP address of the node

ID> controllers in the range of 1 to 20,
e.g. Node 1 has an IP address of
172.29.0.101
Node 1 to 20 172.29.0.120 + <Node The IP address of the node

server ID> controller management port in the
management range of 1 to 20, e.g. Node 1 server
port (iDRAC, management port has an IP address
BMC, etc) of 172.29.0.121
EnableMonitor 172.29.0.140 to If EnableMonitor servers are used at

servers (and 172.29.0.159 the node, assign each one an
iDRAC) address in the range 172.29.0.140
to 159
EnableInsight 172.29.0.160 to If EnableInsight servers are used at

servers (and 172.29.0.168 the node, assign each one an
server address in the range 172.29.0.160
management to 168
port)
Miscellaneous 172.29.0.200 to If third party equipment or network

equipment 172.29.0.252 gateways, e.g. TN9500, are used at
the node, assign each one an
address in the range 172.29.0.200
to 252
Each site is assigned an ID in the range 1 to 100. The third number of the
IP address should be the site ID for site equipment.
Host IP Description
Base Station 172.29.<Site Site ID is a number from 1 to 100

Reciter ID>.<Channel ID> and Channel ID is a number from 1
Channel to 25
Miscellaneous 172.29.<Site ID>.200 to If third-party equipment (such as

equipment 172.29.<Site ID>.252 Digi TS2) or network gateways, e.g.
TN9271, are used at the site, assign
each one an address in the range
172.29.<Site ID>.200 to 252
Secondary 172.29.<Site ID>.253 If a second managed switch is used

Switch or at the site, assign it to this address
Routera
Primary 172.29.<Site ID>.254 If a managed switch is used at the

Switch or site, assign it to this address
Router
a. A secondary switch or router should not be implemented at sites where fallback

mode is required, or if your network has only a single site. In these situations, the
base stations use multicast IP packets within their subnets, and as such would not
function correctly if multiple routers were present.

2.9.3 Example IP Address Plan
The following example shows the IP address plan for a network consisting
of:
■ 2 node controllers
■ 3 sites with 3 channels at each site
■ 2 dispatch consoles
■ 1 PC for general network management
■ 1 network gateway used for cross band repeat at Site 2
Node controllers and related central site equipment:
Host IP Notes
Default Router 172.29.0.254 Equipment provided by customer
Active Node IP 172.29.0.1 Virtual IP for active node
Switch 1 172.29.0.11
Console 1 172.29.0.21 Dispatch Console
Console 2 172.29.0.22 Dispatch Console
Node 1 172.29.0.101 Kontron CG2400
Node 2 172.29.0.102 Kontron CG2400
Node 1 server 172.29.0.121 Kontron CG2400 Management

management port
Node 2 server 172.29.0.122 Kontron CG2400 Management

management port
Site 1:
Host IP Notes
Base station CH ID 1 172.29.1.1 The CH ID is an equipment ID - not the

DMR RF channel number
Base station CH ID 2 172.29.1.2
Primary Switch or 172.29.1.254 Switch connected to customer NTU

Router
Site 2:
Host IP Notes

DMR RF channel number.

Host IP Notes
Network Gateway 1 172.29.2.200 Used for cross band repeat

Router
Site 3:
Host IP Notes

DMR RF channel number

Router
2.10 Network Linking Design
2.10.1 Network Topology
Non-simulcast DMR networks are structured as a star with all traffic

passing through the node controllers.
Network
Element
Node
Controller
Network Network
Element Element
Network
Element
A network element is anything that connects to the node controller, for

example: a base station, network gateway, third party console gateway,
voice recorder, PABX, etc.
For simulcast DMR networks, please refer to the TN9300 DMR Channel
Group System Manual (MNB-00010-xx).

2.10.2 Bandwidth Considerations and Recommendations
Node For a single link (counting all network ‘hops’) between the node and
another element the standard requirements are:
Out of order Ca and Ub traffic packets Less than 0.01%

Packet Loss Less than 0.01%
Latency Less than 40 ms
Jitter Less than 20 ms
Minimum bandwidth to carry C+U traffic 64 kb/s per physical channel
Minimum bandwidth to carry Mc traffic 100 kb/s per site
Minimum bandwidth to meet jitter 600 kb/s per site up to 6 physical
requirements on non-fragmenting link (see channels
non-fragmenting linking and bandwidth below)
AMBE 32 kbit/s per connection
G.711 110 kbit/s per connection
a. C traffic - Control plane traffic such as call signaling, trunked registration,
and mode changes.
b. U traffic - User plane traffic, such as voice or packet data from or to sub-
scriber equipment (e.g. portables, mobiles, dispatchers, PSTN, and data
terminals).
c. M traffic - Management plane traffic for monitoring and configuration. In-
cludes the aggregation of SNMP, HTTPS, Syslog, firmware downloads,
backup/restore, etc.
Configurable delay/jitter buffers in the base station, console gateway or

network gateway must be set to 10 ms plus 2 times the maximum jitter for
a single link.
Minimum delay buffer = 10 ms + jitter x2
For example, if the maximum link jitter is 20 ms, the base station and
network gateway delay buffers should be set to a minimum of 50 ms.
Site For (inter) site linking (both directions, each site) in DMR simulcast
networks, any base stations configured as master voters need to be
dimensioned to accept the aggregate uplink traffic from all satellite
receiver sites.
(n * 64 kbits/sec)
2.10.3 Effect of Not Meeting Timing Requirements
For all systems, increasing network latency causes a direct increase in call
setup delay or voice end-to-end delay.
If the jitter exceeds the specification, the system can be configured to

tolerate the increased jitter by increasing the voice and data delay on base
stations at affected sites, and voice delay at TN9271 analog gateways and
TN8271 network gateways.

It is possible to trade off some of the increased delay caused by jitter against
voice quality by configuring a smaller jitter buffer than the calculations
would require. This will cause some packets to fail to meet timing
expectations. Higher than expected (configured) jitter may result in call
loss though, so it is more important to limit jitter.
The effects of not meeting timing requirements are worse for packet data
and encrypted voice than they are for clear voice. Voice communications
can tolerate some loss/late packets, but data cannot. With encrypted voice,
late entry performance is affected by late/lost packets.
For any delay and jitter outside of the specified limits, system performance
is not guaranteed. In addition, encrypted calls will be more affected by IP
links that are out of tolerance than clear speech. Digital artefacts may also
be heard due to over-the-air encryption synchronization issues caused by
late or missing voice packets.
2.10.4 QoS/DSCP
Strict priority-queuing QoS is required. 8421-type round-robin priority

queuing will typically breach the jitter requirement unless significant
additional bandwidth is available. Marking must be left intact by network
switches and routers. In “Cisco speak” this means that a line such as mls
qos trust dscp must be present in the configuration of every router
through which RF network traffic is carried.
The table below lists the various packet types carried on Tait networks,
together with their recommended DSCP classification, based on their
criticality for the network.
Protocol/Port
Service Class Packet Type DSCP
Number
Expedited Voice data protocol (VDP/ UDP 9050 46 (EF)
Forwarding RTP)
(EF) Base station protocol (BSP) UDP 10001 to 10250 46 (EF)
Channel group status UDP 9018 46 (EF)
protocol (SVP)
Channel group voice UDP 27260 46 (EF)
protocol (CGP)
Voice recorder protocol UDP 9999 46 (EF)
(VRP)
Network gateway protocol UDP 9006 46 (EF)
(NGP)a

Protocol/Port
Number
Assured Node to node TCP 9060 26 (AF31)
Forwarding communications
(AF) Application interface UDP 5060 26 (AF31)
specification (AIS)
TeamPTT TCP/UDP 5062 26 (AF31)
Dispatcher information TCP 9005 26 (AF31)
protocol (DIP)
Session initiation protocol UDP 5060 26 (AF31)
(SIP)
Location Information UDP 11433 26 (AF31)
protocol (LIP)
NTP TCP/UDP 123 26 (AF31)
Mobile IP UDP 434 26 (AF31)
ICMP (echo/ping) ICMP 26 (AF31)
Best Effort Web Interface (http/https) TCP 80/443 0
Domain Name Server TCP 53 0
(DNS)
Secure shell (ssh) TCP 22 0
Syslog UDP 514 0
SNMP UDP 161/162 0
RADIUS authentication UDP 1812 0
LDAP authentication TCP 389 0
DIP monitor TCP 9013 0
Data API Connector UDP 80 0
a. Includes G.711 connector voice traffic
Protocol/Port
Number
Expedited Voice data protocol (VDP/ UDP 9050 46 (EF)
Forwarding RTP)
(EF) Base station protocol (BSP) UDP 10001 to 10250 46 (EF)
Assured Node to node TCP 9060 26 (AF31)
Forwarding communications
(AF) Application interface UDP 5060 26 (AF31)
specification (AIS)
Session initiation protocol UDP 5060 26 (AF31)
(SIP)
Location Information UDP 11433 26 (AF31)
protocol (LIP)
NTP TCP/UDP 123 26 (AF31)
Mobile IP UDP 434 26 (AF31)
ICMP (echo/ping) ICMP 26 (AF31)

Protocol/Port
Number
Best Effort Web Interface (http/https) TCP 80/443 0
Domain Name Server TCP 53 0
(DNS)
Secure shell (ssh) TCP 22 0
Syslog UDP 514 0
SNMP UDP 161/162 0
RADIUS authentication UDP 1812 0
LDAP authentication TCP 389 0
2.10.5 Optimization Techniques for Reducing Bandwidth Requirements
Fragment Linking MiMOMax and routers using the Cisco multilink PPP protocol support
fragment linking. This breaks large lower-priority traffic into smaller
fragments and interleaves them with higher-priority traffic, so limiting
jitter for the higher-priority packets. In this situation the bandwidth
required for each site is smaller than 600 kb/s and is defined to be:
Bandwidth = 64 kb/s x physical channels + 100 kbps
Hence the minimum bandwidth for a single site running over MiMOMax
is 150-190 kbps.
RTP Header MiMOMax also supports RTP header compression, where redundant
Compression information is removed. In this case the bandwidth required for each site
is:
Bandwidth = 50 kb/s x physical channels + 100 kbps
Hence the minimum bandwidth for a single site running over MiMOMax
is 125-175 kbps.
2.10.6 Calculating the Delay Buffer Size
For IP traffic in general, most linking backhaul does not fragment large
packets and interleave small packets within the data link. Because of this,
even if QoS is implemented, large TCP/IP packets (used to carry
management traffic) will cause delays unless the link speed/bandwidth is
high enough so that large packets are transmitted faster than the maximum
jitter time of 20 ms.
A TCP/IP packet of 1500 bytes takes a little less than 20 ms to send at 600
kbit/s. If we accept a higher permitted jitter then less link bandwidth is
required.
Jitter for a single link = (1500 x 8) / bandwidth in bit/s.
The following table indicates the delay buffer size required for different
link rates and maximum packet sizes. The values assume a system latency

of 10 ms and enable operation without impacting speech and packet data
quality.
TCP/IP max packet size Link rate Jitter Delay buffer

Bytes Bits (kb/s) (ms) (ms)
1500 12000 80 150 310
1500 12000 128 94 198
1500 12000 160 75 160
1500 12000 240 50 110
1500 12000 320 38 86
1500 12000 600 20 50
2.10.7 Effect of Delay Buffer Size on End User Audio Experience
The following table shows the effect of the delay buffer size on the end user
audio experience. The end-to-end audio latency excludes call setup delays.
Values over 400 ms are shaded, as they are not normally considered
acceptable. However, exceptions can be made on a case-by-case basis, for
example on networks largely used for one-way dispatch communications.
Delay buffer size (ms) End-to-end audio latency (ms)

310 660
198 498
160 460
110 410
86 386
50 350
2.10.8 Ethernet Connections
The RJ-45 sockets on the servers provide either 10-BASE-T, 100-BASE-T

or 1000-BASE-T Ethernet connections to the other devices in the network.
DMR servers have been thoroughly and successfully tested for both
10-BASE-T and 100-BASE-T.
Use a Cat-5 (minimum) cable for connecting the Ethernet socket to the
network via a router or switch. The Ethernet port speed is auto-negotiated
at start-up.

2.11 Audio Level Planning
Networks have many interfaces through which audio can be passed,
requiring various conversion processes.
A level plan can establish the objective levels at each interface, in units of
measurements applicable to the interface, so that deployment engineers can
get them properly aligned. Without a level plan, audio from some interfaces
may appear much louder or quieter than from others. Signals may become
distorted (level too great for the local circuit) or signals may be excessively
noisy (level too low for the local circuit). It is important that regional
standards for telephony audio levels be taken into account so that levels can
be adjusted as necessary for each network.
Tait’s base station specifications include details about RF interface levels.

In the IP domain, for digital speech the level is set to -25 dBfs. In DMR
networks, the TN9271 analog gateway and TN8271 network gateway are
used to adjust gain into the network. (Refer to the appropriate installation
and operation manual.)
Third party devices may also need to have their own audio levels adjusted.
Be aware that they may have different audio level requirements if they
operate in different modes (e.g. between MPT or DMR Trunking).
Tait may be able to supply technical notes for some recommended

equipment that may be useful for audio level settings.

2.12 Redundancy and High Availability
The TN9300 node controller supports the following redundancy models.
2.12.1 Geographical Redundancy
There can be up to 20 node controllers in a DMR network. One node, the

one with the highest priority, is the control node and the other nodes are
switching nodes, used to share the packet switch load for voice calls.
Regional Network
Node
Control Node
Switching Node
Regional Network
Node
Switching Node
Switching Node
The nodes are usually located at different geographical locations. If the

control node location has power or network issues, one of the switching
nodes from another region can take over as the control node. Automatic
switch-over can also occur when a fault is detected on the control node, in
which case one of the switching nodes, if available, takes over as the
control node.
This feature is integrated into the TN9300 architecture and does not need
any extra licensing, but it does require at least one switching node. Also all
the nodes in the network must be configured the same. If a modification is
made to the control node configuration, all the other switching nodes need
to be modified as well.

However, for automatic synchronization of the control and switching node
databases (recommended,) license TNAS302 is required, see
Section 2.12.4 License TNAS302.
Other network interfaces between the node and third party equipment
needs to be defined carefully as defined in Section 2.12.6 Network
Interfaces.
2.12.2 Redundancy with Active IP
Active IP provides for quick system recovery in the event of a failure of a

major component of the system.
The control node and the switching node that is the high availability backup
server are usually located together, and must be on the same subnet of the
IP network to provide a quick switchover. Whilst they have separate IP
addresses assigned to them, they are configured with the same active node
IP address for ease of hand-over.
This feature is integrated into the TN9300 architecture and does not need
any extra licensing, but it does require at least one switching node. Also all
the nodes in the network must be configured the same. If a modification is
made to the control node configuration, all the other switching nodes need
to be modified as well.
Regional Network
Node
Control Node
Switching Nodes
With the TNAS302 High Availability Node license installed however, the
control node and the switching nodes have their databases synchronized for
convenience. It is highly recommended to avoid having different
configurations on the servers. See Section 2.12.4 License TNAS302 for
more detail.
Other network interfaces between the node and third party equipment
needs to be defined carefully as defined in Section 2.12.6 Network
Interfaces.

Note that the virtual active node IP address is in no way intended as a
substitute for the nodes’ individual IP addresses.
This virtual IP address is used for device connections such as AIS/SIP/

DIP and WebUI access in a multi-node arrangement, and for other
device management messages being sent to the servers. Polling of
devices is always conducted from one of the two actual node IP
addresses.
Given these facts, if you are using an active node IP address, you must
ensure that your firewall will accept incoming and outgoing TCP/IP
communication on all three addresses: the active node IP address as
well as the two nodes’ actual IP addresses.
Examples of Using Case 1 - the node controller does not have an active IP address and it is not
Active IP HA (not recommended):
■ When the AIS client connects to the controller, it uses its physical IP
address
■ The controller then replies with its physical IP address in the SIP
message
Case 2 - Geographically diverse nodes with IP addresses that are not in the
same subnet. The node controllers do not have an active IP address and are
configured as HA:
address
■ The controller then replies with its physical IP address in the SIP
message
It is important that the AIS client is able to support more than one IP
address for this connection. If the control node fails, the AIS client will
need to go through the list of physical IP addresses (that are tried in
sequence) until one allows the client to register.
Case 3 - Nodes with IP addresses that are in the same subnet. The node
controllers are configured for HA and have an active IP address:
address
■ The controller then replies with its active IP address in the SIP message
It is important that the AIS client is able to support more than one IP
address for this connection. If the control node fails, the AIS client will
need to go through the list of physical IP addresses (that can be tried in
sequence) until one allows the client to register.
If the AIS client does not support more than one IP address for this con-
nection it could use the active IP address, but this is not recommended
because if the active IP fails, the connection to the controller is lost
(since active IP is managed by the node).

2.12.3 IP Backbone Redundancy
To provide redundancy in case of IP equipment failure, the node can be

configured to support a dual Ethernet configuration with the same IP
address.
To Sites
To Sites
Central location Ring

Network
(example)
Node Controller
Same for dispatch,

To Sites
monitoring equipment, etc.
Adding support for Dual Ethernet connections via Ethernet bonding3

(TaitCentOS), or IPMP (Solaris), is intended to allow for provision of
redundancy in case of an Ethernet switch failure or link failure, as the DMR
node may now connect to two independent switches.4
If the interface which has the active node IP address fails, the other
interface in the group/bond will become active and take over use of that IP
address.
For further information about IP backbone redundancy, refer to the TN-

2325 DMR Node Dual Ethernet Support technical note.
2.12.4 License TNAS302
Each node in the DMR network has its own database containing
configuration and unit registrations. The high availability license enables
the synchronization of the node databases so that if a hand-over occurs,
then the new control node is using a current set of data. This does not
include simulcast, so for channel group manager application
synchronization, see Section 2.12.7 High Availability in Version 3 and
Version 4 DMR Simulcast Systems.
Without this license, switching nodes will have out-of-date information,

which may cause undesirable behavior in the event of a failure that causes
a control node hand-over.
3. Ethernet bonding is not currently supported in Tait Ubuntu.

4. For more information on ethernet bonding, refer to TN-2325 DMR Node
Dual Ethernet Support.

Note that this feature is not available for DMR Express6 systems.
2.12.5 High Availability Setup
Automatic switchover occurs when a fault is detected on the controlling

node. One of the switching nodes, if available, takes over as the control
node.
This feature does not provide uninterrupted hand-over when control moves
to another node. In general all calls will be cleared as a result of a
switchover.
The following settings are required.
Name Purpose Example
IP address The fixed individual IP address for a 192.168.1.10

node controller.
Active node IP address The floating IP address that is available 192.168.1.1

when the node is in control
Priority The priority of this node that is used 1

between nodes to negotiate which one
should be in control. The lowest number
has priority
Nodes table A list of all node controllers in the

system. This table needs to include all
nodes - even itself.
The active node IP address is used by multiple node controllers that are in
the same subnet. The use of the gratuitous ARP protocol requires high
availability nodes to be in the same subnet.
When a node is the control node it will be available via either its primary
IP address or the active node IP address. This allows connecting devices to
only be configured with one IP address for connecting to nodes in that
subnet.
Even with the use of the active node IP address, in the event of a hand-over
the connecting devices will still see the connection drop, and will need to
reconnect and login.
The active node IP address is only used for nodes on the same subnet.
2.12.6 Network Interfaces
Third-party applications such as dispatcher consoles and SIP devices need

to support connections to multiple nodes. In the event that the connection
to a node fails, these applications should try to connect to one of the other
nodes.

There is no easy way to determine which node is the new control node. One
method is to try each one in priority order. Usually if a node fails, the next
in priority will take over, so it would be rare that all 20 nodes would need
to be tried before finding the control node.
Interfaces on the node such as DIP, AIS and SIP will reject incoming
connections unless they are from the control node.
If Active IP is used, it is important to check that all interfaces, i.e. telephony

(SIP lines), AIS connections, DIP connections, and especially, INP
connections, are configured using the active IP address for connecting to
the control node (not the server’s physical IP address). This is because in
case of a switchover, the external interface needs to be able to connect to
the new node using the active IP address.
2.12.7 High Availability in Version 3 and Version 4 DMR Simulcast

Systems
In DMR v3 (TaitCentOS) and v4 (Tait Ubuntu) systems the following

limitations apply to redundancy/high availability.
Switchover The operation of the control node is not affected by the status of the other
modules (e.g. administration application or channel group manager). If one
of the other modules on the node fails, the control node has no way of
detecting this and will not switchover.
This means that in networks with more than one node controller server, the
control node’s controller application will not check if the channel group
manager is running on the server. If there are simulcast channels, the
controller application will not check the status of the channel group
manager application, therefore no switchover will happen if the channel
group manager application fails.
If the channel group manager has failed, try the following:

■ Try to restart the channel group manager application from the
administration application
■ Put the controller with the failed module offline to allow a switching
node with a working channel group manager application to take over
Synchronization The channel group manager module of the control node does not
synchronize its database to the switching nodes with HA licenses.
This means that after every configuration change, the channel group
manager database has to be backed up and restored as follows:
1. Connect to the control node.
2. Select the Channel Group Manager module and login.
3. Select Files > Backup and generate a backup file.

4. Download the generated backup file.
Each switching node must then be updated as follows:
1. Connect to the switching node.
2. Select the Channel Group Manager module and login.
3. Select Files > Backup and load the backup file generated on the
control node’s channel group manager module (above).
4. Restore the backup file.
2.13 Speech Call Capacity

The maximum number of subscribers is limited by the address space
defined in the DMR numbering scheme. That allows for approximately 16
million addresses divided amongst individual subscribers and group
addresses.
A more useful measure of network capacity is the number of successful

speech calls that can be handled within a specified time. On a typical
trunked network, there are a large number of users and a far smaller number
of channels. Any user can be assigned any traffic channel. This is similar
to a telephone system where any long-distance user can be assigned any
link on a trunked connection between cities. The number of users that a
system can comfortably support can be estimated using probability theory.
In theory, 60 local calls of one minute duration can be made on each

channel every hour. In practice, the capacity of the network is not fully
utilized because network traffic varies during the day. Other factors, such
as seasonal peaks in demand and emergency calls (which may be very long)
need to be taken into account. To calculate network capacity, one must
consider the busy hour rather than the average load over a 24 hour period.
The following formula calculates system utilization. The traffic load (or
carried traffic) is the average number of concurrent calls per unit time, and
in a system with 100% utilization, the number of erlangs will be equal to
the number of traffic channels.
t call
Load (erlangs) =
N .t
Where:
■ tcall is the summed duration of all calls
■ N is the number of channels
■ t is the time over which the load is measured

On a busy network, a user may not be able to make a call. They may have
to wait in a queue until a traffic channel becomes available. The more users
per channel, the more often they must wait and the poorer the quality of
service. If service is very poor, queues become overloaded and some calls
are even blocked.
The MPT 1318 engineering memorandum defines grade of service as the

probability that a user has to wait for more than 20 seconds for a call to be
connected. Counter-intuitively, this results in good grades of service being
represented by low values. Poorer grades of service are reflected by
progressively higher values.
Grade of service can be calculated from the following equation (from

Erlang-C theory):
N
A ( - (N - A) t / H)
P ( > 20s) = N-1
e
n
A
A + N! (1 - a)
n!
n=0
Where:
■ N is the number of channels
■ a is the load in erlangs
■ A = N·a
■ H is the mean call duration
■ t is the time to wait for service
The following graph shows that for a specified grade of service, the system
utilization improves as the number of channels increases. Ultimately,
adding more channels helps but the relationship between grade of service
and number of channels is not linear: adding more channels produces

diminishing returns. The maximum number of traffic channels shown is 23.
H is set to 35 seconds and t is 20 seconds.

2.14 Data Support
Tait DMR networks support data communication. They integrate voice and
data in a single network and are suitable for low-bandwidth data
applications such as:
■ AVL (automatic vehicle location) services, using either short data
messages, USBD polling over the control channel, or USBD polling
over the alternate channel. With USBD over the control channel, the
control channel supports four polls per second, versus two for short data
messages. With USBD over an alternate channel, the alternate channel
supports 1000 polls per minute (see Section 3.1.27 Fast Polling). AVL
and other applications can also send IP-based data over the traffic
channel. See the DMR Data Integration Guide (TD-0044-02 or later) for
more information.
■ SCADA control applications (see Tait’s GridLink System Overview,
TD-0017-xx)
■ Tait mobile radios are equipped with a serial data port for direct
connection to data peripherals such as a GPS receiver or laptop
computer
■ Radios and dispatchers can exchange pre-defined status messages. A
code is sent over the control channel, whose meaning is known by the
receiver(s). A lookup table maps the code to its meaning. 128 status
codes are available.
■ The dispatcher or a radio can also send a radio user or group free-form
text, that can be read from the radio’s LCD screen
■ Data-over-IP interfaces are available for connection to third party data
applications:
a. AIS (Application Interface Support) is part of the DMR standard.
b. Packet data can also be sent across a DMR network using the
Dispatcher Interface Protocol (DIP) and Radio Access Protocol
(RAP) with various payload types, as in the following diagram.
Server
DMR RAP
application
Radio 1 Client
application
DIP RAP
BSP Base station DMR
Radio 2 Client
application
DMR node controller

DMR
BSP
RAP
Base station Radio 3 Client

application
The following data features are available:

■ Status messaging on the control channel (send a number 0-127)
■ Short data messaging on the control channel (send a short message up
to 50 characters long)
■ Unconfirmed packet data on a traffic channel (up to 1500 bytes per
message)
■ Confirmed packet data on a traffic channel (up to 1500 bytes per
message)
2.15 Packet Data Transfer Times

The following tables provide transfer times for various FEC rates and
packet sizes. They do not include overheads for MAP27 serial port
transmission.
Unconfirmed
Dual Slot Single Slot
Packet Size Full 3/4 1/2 Full 3/4 1/2
Rate Rate Rate Rate Rate Rate
50 bytes 0.18s 0.18s 0.24s 0.27s 0.27s 0.39s
100 bytes 0.24s 0.27s 0.36s 0.39s 0.45s 0.63s
150 bytes 0.3s 0.36s 0.48s 0.51s 0.63s 0.87s
200 bytes 0.36s 0.45s 0.6s 0.63s 0.81s 1.11s
250 bytes 0.42s 0.54s 0.75s 0.75s 0.99s 1.41s
500 bytes 0.72s 0.93s 1.35s 1.35s 1.77s 2.61s
750 bytes 1.05s 1.35s 1.98s 2.01s 2.61s 3.87s
1000 bytes 1.35s 1.77s Not 2.61s 3.45s Not

supported supported
Confirmed No
Retries Dual Slot Single Slot
50 bytes 0.3s 0.33s 0.39s 0.39s 0.45s 0.57s
100 bytes 0.36s 0.42s 0.54s 0.51s 0.63s 0.87s
150 bytes 0.42s 0.51s 0.69s 0.63s 0.81s 1.17s
200 bytes 0.51s 0.6s 0.84s 0.81s 0.99s 1.47s
250 bytes 0.57s 0.69s 0.99s 0.93s 1.17s 1.77s
500 bytes 0.9s 1.17s 1.74s 1.59s 2.13s 3.27s

750 bytes 1.26s 1.65s 2.49s 2.31s 3.09s 4.77s

supported supported
Confirmed 1 Retry
50 bytes 0.6s 0.63s 0.69s 0.75s 0.81s 0.93s
100 bytes 0.66s 0.72s 0.84s 0.87s 0.99s 1.23s
150 bytes 0.72s 0.81s 0.99s 0.99s 1.17s 1.53s
200 bytes 0.81s 0.9s 1.14s 1.17s 1.35s 1.83s
250 bytes 0.87s 0.99s 1.29s 1.29s 1.53s 2.13s
500 bytes 1.2s 1.47s 2.04s 1.95s 2.49s 3.63s
750 bytes 1.56s 1.95s 2.79s 2.67s 3.45s 5.13s

supported supported
2.16 Network Time Protocol

Time synchronization is essential for computer networks, especially those
that conduct time sensitive transactions. Time, in the form of timestamps,
is used by computers to identify when a transaction has taken place or
needs to take place. Therefore, if time differs across a network then all sorts
of things can go wrong, from transactions not occurring to data getting lost.
Because of the importance of time for computer and technologies, a time

server system is required to not only keep all devices on a network running
at the same time, but also to ensure that different computer networks that
speak to each other are also synchronized. This is where NTP comes in.
Customers can contact Tait for assistance in installing/configuring an NTP

server if required (the TN9300 Node can act as an NTP server for small
networks).
There are also two technical notes that can be used for reference:
■ TN-2674 Providing Synchronization to Tait Networks
■ TN-1779 Running an NTP server on the TN9300 DMR Node Controller
(this is applicable only to Solaris and TaitCentOS 6)

2.16.1 What is NTP
Network Time Protocol (NTP) is a software algorithm that keeps

computers and other technologies synchronized to within a few
milliseconds of each other (thousandths of a second), but it can only do this
if it has a reliable form of time with which to use as a master time source.
For their master time source, most NTP networks use Coordinated
Universal Time (UTC). This is because UTC is not only the same no matter
what time zone you are in, but also it is kept accurate by a constellation of
atomic clocks. These clocks ensure that UTC is maintained to extreme
precision, and getting a source of UTC time requires using an NTP time
server.
For Tait networks, NTP can be provided through a GPS sourced unit as part
of the system sale, or the customer may optionally provide their own. It is
recommended that all the network elements be synchronized to an external
NTP source connected to an atomic clock. If this is not the case, then at
least they should all be synchronized to the same source even if it is not
connected to an atomic clock.
Tait recommends the use of NTP for the reasons outlined below. It is a
compulsory requirement for Tait networks using DMR Mobile IP, but is
only optional for high availability systems.
2.16.2 NTP Prevents Network Problems
Having an NTP time managed network can prevent all sorts of problems.
Because timestamps are the only method with which computers can tell
whether a transaction has occurred or not, if several devices on a network
are running different times, errors can easily occur as the network won’t
know which timestamp to trust. This could lead a network to believe a
transaction has taken place when it hasn’t, a transaction being repeated, or
data becoming lost. This is because to store any data, a system needs a
timestamp in order to store the information. However, if that timestamp
differs between machines, the system may believe the data has already
been stored, leading to information being discarded.
NTP time synchronization is also critical for auditing and managing a

system. If a system is infiltrated by a piece of malicious code or an
unauthorized user, tracking down where and when this happened can only
be done with an accurate timestamp. Furthermore, if fraud or another
criminal act takes place, a system that is synchronized with an NTP time
server will have an auditable trail, and because the time comes from an
atomic clock source, it is irrefutable, and can therefore be used in any
potential legal proceedings.
An inaccurate network is also highly insecure. Time discrepancies allow

malicious users and software to wreak havoc on a system. In addition, not
having accurate time can mean that putting things right is almost
impossible. Without accurate timestamps, debugging and identifying
breaches can be extremely difficult.

2.17 Centralized Authentication
IT security is vital for police, utility and public safety organizations. Lives
may depend on their ability to block unauthorized access to data and
communications. IT security has become a standard government
requirement for such organizations.
Passwords restrict access to data and communications, but what happens

when a password is compromised - for example when staff leave the
organization?
Formerly, a compromised password had to be revoked at each network

element where it was registered - a time-consuming task for networks with
hundreds of elements.
Tait’s centralized authentication feature, AAA, streamlines this process and

is now a standard security feature of all new Tait networks, including DMR
products.
Centralized authentication is used for logging on to the node WebUI

only, not for ssh. If centralized authentication is to be used, it is recom-
mended that other means of access be disabled.
2.17.1 AAA Security Feature
AAA stands for:

■ Authentication: confirming that a user is who they claim to be
■ Authorization: centralized control over all authentications on a system
■ Accounting: providing an audit trail
The AAA security feature provides:

■ Centralized control over all who use an IT network
■ The ability to grant access to a network and define the level of access
■ The ability to change or terminate the level of access of a specific user
■ A record of all attempts to access the network
It was designed to be compliant with NERC CIP-004-3a (Personnel and

Training) requirement 4.2, which requires the ability to revoke access to a
network within 24 hours.
2.17.2 How AAA Works
TN9300 networks can be set up with centralized authentication. When you

ask to connect to a server or base station, your request is passed on to an
AAA server, which replies indicating whether you are permitted to connect
and what your user privileges are. The server or base station then replies to
you, granting or denying access.

All user authentication data for a network (in particular logins, passwords
and access privileges) is stored with a third-party server and database. Each
attempt to access the network is passed on to this external agency, which
authenticates the login and password and authorizes access. It also records
the access attempt.
AAA server &
user directory
database
Authentication Authentication
request response
Login/
password
Access
granted/denied
Network users LMR network
(maintainers &
administrators)
A network user with administrator privileges provides the external

database with a user’s initial authorization, and can also revoke that
authorization; both operations being immediately effective network-wide.
For configuration information, see Section 5.15 Configuring Centralized

Authentication.
2.17.3 Network Protocols
AAA servers most commonly use one of two network protocols: LDAP or
RADIUS. The Tait AAA system supports both.
Current limitations ■ Start TLS method (TLS extension on port 389 by default) not supported
for LDAP in version 2 node controllers
■ No support for LDAP referrals
■ Nested groups not supported
■ LDAPS (LDAP over TLS on port 636) not supported
■ No support for posixGroups format (no support to memberUid
attribute), only LDAP Core schema is supported, i.e. groupOfNames or
groupOfUniqueNames format (member or uniqueMember attribute
containing the full user DN)
■ No support for TN8271 network gateway
Current limitations ■ Accounting functions not supported

for RADIUS
■ No support for unsolicited messages sent from the RADIUS server
■ No support for TN8271 Network Gateway

3 Network Features and Interfaces
3.1 Features
3.1.1 DMR Tier 3 Trunking
Tait DMR networks comply with the open, non-proprietary DMR ETSI
standard. Production of equipment according to this standard does not lie
with any one vendor, so network owners are not locked into obtaining their
equipment from one particular supplier. Interoperability between
equipment from different suppliers is assured by the DMR Association’s
interoperability testing process.
DMR is a flexible standard, not developed exclusively for a specific

market. It is well suited to become the dominant standard for operation-
critical networks such as those found in transport, industrial radio networks
and utilities.
The network is trunked, providing benefits such as access control, call

queuing and more efficient use of channels. It follows the DMR Tier 3
standard (it is important to check whether a vendor’s trunked DMR
offering follows the DMR Tier 3 standard).
As a digital standard, DMR provides a constant level of voice quality over

a wide range of signal levels, whereas analog systems exhibit a gradual
degradation as the signal attenuates.
DMR offers two TDMA channels over a 12.5 kHz channel, providing
6.25 kHz equivalence voice calls.
The system utilizes a dedicated control channel for control messages.

The control channel also supports status, text and GPS/AVL messaging.
3.1.2 Interoperability
Radio Support Tait DMR radios are trunked but also support a basic level of
interoperability. They can seamlessly roam or be manually switched onto
another organization’s conventional analog FM or trunked MPT network.
Infrastructure Tait DMR trunked networks can enable an analog FM talkgroup to join a
Support DMR talkgroup. The DMR network interfaces to analog FM base stations
via gateways, see “Analog FM Base Stations” on page 116. This interface
offers a fixed mapping between a DMR talkgroup and an analog FM
channel or a group defined by DCS code or CTCSS tone. Dispatch
equipment can provide a dynamically defined patch-style interface.
Tait TN9300 DMR Tier 3 Trunked System Manual Network Features and Interfaces 71
Between DMR As different manufacturers bring DMR Tier 3 products to market, Tait will
Vendors actively work with the DMR Interoperability Process (IOP) to test and
certify that different vendors’ radios and infrastructure work together.
3.1.3 DMR Standard Features
The DMR standard defines system level characteristics that all DMR
systems will have in common. The following table lists the significant
attributes inherent in the DMR standard.
Attribute Description
Alternate (or fast The control channel alternate slot (TSCCAS) can be
polling) channel configured for high capacity location polling using USBD
data transport
Channel The channel authorization feature provides a handshake so

authorization that enabled radios can determine when they have won the
floor. This reduces uplink collisions where, on trunked or
conventional channels, radios may press push-to-talk at the
same time.
See Section 3.1.8 Channel Authorization for more details.
DMR dialing DMR trunking systems support the DMR standards-based

fleet numbering and dialing plan as defined in Annex E of
ETSI TS 102 361-4 V1.11.1 (Part 4: DMR trunking protocol)
for DMR trunked (Tier 3) operation. This new dial plan
forms an extension to the supported dial plan, thereby
retaining backward compatibility with existing schemes
(ANN, MPT 1327, and MPT 1343).
DMR standard Each site has an assigned priority, and vote now messages
priority vote now contain the priority of both the current site and the site to be
voted on. Radio units can be configured whether to use the
priority field or not. When enabled, radio units will use the
site with the highest priority.
Frequency bands The system can be implemented in any licensed frequency

band from 50MHza to 980 MHz.
Modulation The modulation employs a 4 level frequency shift key

(4FSK) format. This is considered to provide extremely
robust digital communications and fits well within existing
land mobile radio spectrum planning. DMR channels can
be allocated adjacent to existing 12.5 kHz analog channels
without any interference on the analog users. This
performance can be achieved re-using existing site RF
antenna equipment.
72 Network Features and Interfaces Tait TN9300 DMR Tier 3 Trunked System Manual
Attribute Description
Spectrum efficiency The DMR system provides increased frequency efficiency

over traditional analog FDMA configurations by the
following two methods:
■ TDMA offers two independent traffic channels (either
can be voice or data) over one 12.5 kHz RF channel.
■ A single base station can support a control & traffic
channel using the same spectrum and RF equipment as
a conventional 12.5 kHz channel, and can deliver all the
call control and radio resource management advantages
of trunking.
Standards DMR is an open, non-proprietary ETSI standard. The suite

of open standards covers system design, air interface and
testing to ensure DMR is not vendor proprietary.
The applicable standard is ETSI-TS102 361-1.
TDMA Each time slot occupies 4800 bit/s per voice channel.
Two voice channels are supported at the same time on one
12.5 kHz RF channel with each occupying ~30 ms slot
periods. This provides 6.25 kHz equivalent operation and
meets the ultra narrow-banding regulations of almost all
countries in the world.
Transmit interrupt DMR Transmit Interrupt is a standards-based feature

defined in the DMR Trunking Protocol specification (ETSI
DMR Part 4); and provides the ability to remotely de-key a
radio that is transmitting voice or data.
Refer to Section 3.1.25 Transmit Interrupt for more
information.
USBD DMR trunking systems support Unified Single Block Data

(USBD) PDUs which offer an efficient single block data
polling and transfer capability over the control channel or
control channel alternate slot (TSCCAS). This mechanism
can be used to improve existing polling rates for location
services. USBDs are supported on the alternate slot of the
control channel.
Voice Vocoder The vocoder selected by the DMR Memorandum of

Understanding (MoU) is the DVSI AMBE+2 half rate
vocoder with a bit rate of 2400 baud excluding any FEC.
While the vocoder choice was not specified as part of the
DMR standard, manufacturers have settled on a common
choice under a DMR MoU charter.
a. The lowest frequency band offered by Tait's TB9300 and TB7300 base stations is
B1 band (136MHz). The lowest frequency band offered by Tait's TB9400 base sta-
tion is B3 band (148MHz).
3.1.4 Tait DMR System Features
The following table outlines the relevant features that Tait DMR supports.
Feature Description
Access priority Five priority levels exist (Emergency is the highest priority
levels level):
■ No priority - normal
■ Priority 1 - low
■ Priority 2 - medium
■ Priority 3 - high
■ Emergency
Adaptive channel When enabled, this feature speeds up the unit’s re-entry
grant (or GTC in time to a group when it hunts to a new site by sending
MPT) channel grants at an adapted rate. It does this when the
unit registers or when it affiliates to a group, if that group is
also configured to support adaptive channel grants. The
unit is then sent a channel grant for the highest priority
group that it is affiliated to, if a call for that group is currently
on channel.
Note that, when a unit registers, an adaptive channel grant

will be sent after any optional transactions have been
completed (e.g. authentication, IP registration, group
registration or normal registration). However, the adaptive
channel grant will only be sent if this feature has been
enabled in both its unit profile and the group profile for the
active group call.
Adjacent site The node can be configured to broadcast information to the

information radio units about adjacent sites. A radio unit will only use
this information to move if it loses contact with the site it is
currently on. Note that the DMR specification must be 1.6.1
or higher (Settings > Network Parameters > Compliance).
AES voice AES 128 and AES 256 encryption and decryption (if
encryption installed) is available for radio-to-radio and radio-to-group
calls and for voice calls involving external interfaces such
as MPT gateways, phones, AIS, SIP, DIP, and VRP. Note
that audio to and from these external connections is
unencrypted. AES offers a higher standard of encryption
than DES.
Audio latency Latency time from the PTT of the ‘a’ party, including call
setup time, to the audio out of the ‘b’ party has a mean
value of 400 ms.
Due to the slotted and random access nature of the control
channel, this is a mean value assuming a relatively idle
control channel.
This could be longer in calls with late entry with encryption.
Automatic Vehicle The DMR system provides the facility for transferring GPS
Location information from mobiles and portables and making this
information available via a network connection. Tait Mobile
radios support direct connect GPS receivers and Tait
Portable radios include an internal GPS receiver. (See TD-
0044-xx for more information on AVL.)
Feature Description
Bar Selective radio barring can be performed via the node

configuration interface in order to prevent a radio from
registering on the network or from accessing any network
services. The radio will still be in working order however,
and may register and operate on a different network.
Call processing Call processing is distributed between the sites and nodes.
Calls between users on the same site are known as local
calls. Calls between users on different sites are referred to
as intersite calls.
Call queuing A call will be queued if:

■ it requires a traffic channel, and all traffic channels at
that site are busy
■ it is an emergency call to a radio that is busy in a non-
emergency individual call with no other calls queued to
that party
■ it is a control channel call to a radio that is busy in an
individual call
Call setup times As DMR employs synchronous data transmission on the

control channel, call setup time can vary depending on
when a PTT is pressed relative to the mobile-to-base
station control channel slot.
■ For a single site individual to individual call the best case
call setup time is 210 ms.
■ For a single site talk-group call the best case
performance for a Tier 3 talk-group call is 220ms.
■ Multi-site call setup times are based on single site times
with the addition of network propagation and node
processing delays. As intersite connection delays and
the overall IP network topology is not known at this
stage figures for multi-site call setup times cannot be
offered.
Call types General call options include:

■ Emergency calls
■ Broadcast calls
■ Priority calls
■ Divert own call
■ Status calls
■ Group calls
■ Individual calls
■ Telephone calls*
■ Packet data
■ Mobile IP
■ Self test
* AIS consoles cannot initiate individual calls to telephone

connections of any type, SIP or analog (even with diversions in
place). This is due to addressing limitations in AIS and therefore
affects all AIS connected devices (e.g. consoles).
Feature Description
Caller ID For individual calls, user radios display the ID of the radio
initiating the call. For group calls, user radios display the ID
(or alias if it is programmed) of the radio initiating the call.
The user ID alias of the subscriber initiating the call is
displayed on dispatch consoles for both group and
individual calls. In addition, the ID of the talking party in a
group call can be displayed on a radio and dispatch
consoles.
Centralized When you ask to connect to a server or base station, your

authentication request is passed on to an AAA server, which replies
indicating whether you are permitted to connect and what
your user privileges are. The server or base station then
replies to you, granting or denying access.
Channel rotation Traffic channel rotation enables calls to rotate through the
available traffic channels, resulting in equal use of all
channels. Each consecutive call at the site is set up on the
next highest channel. When the highest channel number is
reached, the next call will set up on the lowest available
channel, thus forming a rotational channel allocation
pattern.
Use of this feature can extend the life of base stations by
keeping the average temperature down.
Color code DMR color code signaling provides a function similar to

squelch, which ensures that radio users only hear other
radios with the same signaling. In Tait DMR trunked
networks, Tait radios can derive color code from the control
channel and use this for all activity on the site including
payload channels. This allows for the management of
spectrum re-use within the same network.
Control channel Control channel reassignment timeout makes it possible for

reassignment the node to regularly re-assign the control channel
responsibility to another channel. This is only
recommended if there is a compelling (for example
regulatory) reason to change the control channel at
intervals.
Channels that can be reassigned to be the control channel
are those that have been enabled as control channels.
Channels that are only enabled as traffic channels will
never be reassigned to be the control channel.
Feature Description
Critical site Critical site assignment is covered by the Tait Essential Site
assignment feature:
■ A talkgroup can be configured so that calls to the group
must include any sites marked as essential sites for that
talkgroup. If a site marked as essential is busy for more
than the maximum configured queuing time when a call
is initiated to the group, then the call is aborted. Note
that a group call made at the Emergency level will pre-
empt calls in progress to make a traffic channel available
if necessary.
■ When a TN9500 Inter-Network Gateway is used, the
linked networks are autonomous, so their essential sites
will not be recognized by each other. If a group call is
made on network A, with a party of the call on network
B, network A will assign resources to the call when it can
and network B will do the same (independently). This
means that if network B is busy (no resources available),
the call will be queued on network B only, as linked
networks are considered non-essential. If network A is
busy (no resources available), the call will be queued on
network A only, and resources will be allocated on B
until the call times out.
DES voice DES encryption and decryption is available for radio-to-

encryption radio and radio-to-group calls and for voice calls involving
external interfaces such as MPT gateways, phones, AIS,
SIP, DIP, and VRP. Note that audio to and from these
external connections is unencrypted.
Dispatch console Tait DMR supports AIS version 1.0 and this implementation
interfacing will be updated to stay aligned with the evolvement of AIS.
Dual / triple / quad Tait delivers radio solutions that offer conventional analog
modes of operation FM, MPT 1327, DMR conventional and DMR trunked
operation. This offers flexible system planning options for
legacy & migration support.
Dual control On sites with a high number of traffic channels and/or a

channels large quantity of data communications, a second control
channel may be used.
Dynamic The system provides a dynamic regrouping capability from

regrouping the Network Controller. This allows the system
administrators to allocate radios to specific groups.
Dynamic site Dynamic site assignment is provided by the Tait

assignment ‘Registration Based’ group feature:
■ A talkgroup can be configured so that calls to the group
will only use sites that have one or more radios
belonging to the group. This improves spectrum
efficiency and ensures that only sites with radios
registered on those sites are included in group calls.
Tait supports both a proprietary mechanism to support
backward compatibility (Talkgroup Affiliation), as well as a
DMR Standards based mechanism (Talkgroup
Subscription).
Feature Description
Emergency call Emergency calls shall take precedence over all other calls.
pre-emption Emergency call may be pre-emptive causing another call to
be cleared down if the resource requested for the
emergency call is not available.
Fast hunt Radio units use network broadcasts to determine which

sites are adjacent to the currently acquired site and perform
an initial hunt of only those sites to ensure minimum
interruption to service when roaming.
The network and radio units can be configured to only ever
use either logical channel 1 or logical channel 2 of a
physical channel to reduce hunting times further.
Fast polling Utilizes USBD polling services over an alternate channel to

provide a sustained polling capacity for AVL of up to 1000
polls & responses per minute, per alternate channel per
site.
Polled AVL data is made available on the node and on
various network interfaces for client applications including
DIP, monitoring services and LIP.
Network security The network is protected against cyber attacks and

provides secure management and configuration access.
For full protection, especially when connected to the
internet or other networks of your organization, the
deployment of firewalls is recommended.
Operational Subscriber Radios -30 to +60 °C

temperature ranges Base stations -30 to +60 °C
Node Equipment:
Kontron CG2400 -5 to +55 °C
Dell R250 +10 to +35 °C
Aleutia R50 -15 to +50 °C
Sintrones SBOX-2621 -30 to +60 °C
Packet data A dispatcher or radio can initiate a packet data call that
allows confirmed or unconfirmed data to be sent on a traffic
channel. Useful for sending large payloads. Note that if Tait
radios receive a channel grant for a voice call in the middle
of an existing packet data call, the radios’ default behavior
is to leave the current data call and join the newly setup
voice call.
Radio registration Radio registration is supported by a combination of the

following features:
■ registration by random access
■ immediate acknowledgement
■ registration accepted, refused or denied
Radio roaming Seamless roaming allows radio units to roam freely within
the parts of the network where they are authorized to have
service.
Feature Description
Registration A mechanism used to overcome:

timeout ■ Stale registrations when using dynamic site assignment
can cause more sites to be used per group call than
necessary
■ AVL polling and other control channel messaging for Not
Home radios unnecessarily consumes control channel
capacity, and can cause brief but noticeable call queuing
RF output powers The following output power ranges are available:
VHF UHF 700/800 MHz

Portable 5W 4W 3W
Mobile 25/50 W 25/40 W 30/35 W
Base station 50/100 W 40/50/100 W 50/100 W
Shared channel This feature can be used on networks where dedicated

operation frequencies may be limited, and license provisions may
require a shared frequency channel to only be occupied for
a limited time. See Section 3.1.29 Shared Channel
Operation for more information.
Simulcast Simulcast refers to the process of transmitting the same

signal from different tower locations over the same
frequency at the same time. Please refer to the TN9300
DMR Channel Group System Manual (MNB-00010-xx).
Status messaging Radios and dispatchers can exchange pre-defined status

messages. A code is sent over the control channel, whose
meaning is known by the receiver(s). A lookup table maps
the code to its meaning. 128 status codes are available.*
All status messages are given access level priority 1 by
default.
In DMR Standard version 1.7.1 and later, status messages
of 100 and above are reserved; therefore status messages
using these values may not be successful
* The following status codes are preset and cannot be altered:

■ 0 - Join dispatcher queue (99 is recommended for Leave
dispatcher queue)
■ 123 - Call terminate
■ 124 - System status used to cancel an emergency alarm
■ 125 - Transmit interrupt
■ 126 - System status used for an emergency alarm
■ 127 - Poll for status using status polling service
Feature Description
Stun/Revive Selective radio inhibit (stun) and revive can be performed

from the dispatch consoles or via the node configuration
interface
■ Most types of stun/revive and also authenticated stun/
revive are supported
■ If configured, authenticated stun and revive operations
provide increased security
■ In stun mode, the stunned radio is able to register on the
DMR node and is contactable by the network but it is
prevented from performing or receiving any calls
■ If the mobile or portable radio does not support stun
commands, or if it rejects the authenticated stun
messages as per the DMR standards, the DMR core
network will consider the radio as pending stun: it won't
be able to initiate calls but can receive them. It is
important to check the radio fleet’s configuration before
using this feature.
Subscriber roaming Seamless subscriber roaming allows radio units to roam

freely within the parts of the network where they are
authorized to have service.
Tait adaptive vote This is a Tait-customized vote now feature where the vote
now now offset threshold and vote now margin can be adjusted
per site. By setting these levels you effectively configure
how to either make radio units hold on to one site for as
long as possible, or jump to another site faster. This feature
is for use on those sites that have better capacity than
others; where it is beneficial for the radio units to stay on
the site for as long as possible. See Section 3.1.13
Adaptive Vote Now for more information.
This feature requires TN9391 Node Controller version

2.20.06 and TP9300/TM9300 DMR radios version 2.18.02
or later.
Tait group affiliation The system supports Tait group affiliation for subscribers.
Dispatch consoles are capable of monitoring multiple talk
groups.
Currently there is no arbitration when two consoles attempt

to PTT on the same talk group. The first console floor
request received by the node will be granted.
Text messaging The dispatcher or a radio can send a radio user or group
free-form text, which can be read from the radio’s LCD
screen.
Feature Description
Trunking modes* There are two types of trunking mode:

■ message trunking - where the traffic channels required
for the call are reserved for the entire call
■ transmission trunking - where each over of the call is
treated as a separate call, and may therefore use many
different traffic channels (see Section 5.12 for
configuration instructions)
Message trunking is the most widely used trunking mode,
whilst transmission trunking can sometimes allow for better
traffic channel utilization (although more control channel
resource is required in this mode) and better PTT
contention management.
Note that transmission trunking is voice only and only
available when using broadcast group calls.
* It is recommended that all external interfaces be tested in the

required mode, to ensure expected operation. Note that
transmission trunking will require equipment with fast response
times to avoid instances of late entry.
Voice recorder The DMR system provides the ability to record the audio for
interfacing each voice call. The node sends Voice Recorder Protocol
(VRP) packets to the IP addresses configured in the node
controller.
3.1.5 Ease of Migration
Migration from an analog network to a Tait DMR network is easy and cost
effective, especially if the analog network uses the same 12.5 kHz channel
spacing as used by the DMR network. In such cases the antennas’
combiners and other RF site equipment can be re-used. TN9271 analog
gateways are used to facilitate communications between those still on the
old analog network and those on the new DMR network.
For migration from analog FM or MPT 1327, the Tait radios provide triple
functionality: DMR, MPT 1327 and Analog FM.
The use of TDMA means that there will be an effective doubling of logical
channels which doubles the network’s voice capacity. Coverage of a digital
DMR base station is comparable with coverage of the analog equivalent, so
additional transmission towers need not be built.
3.1.6 Scalability
A Tait DMR network is scalable from a single site with one base station to
a large, wide area network with multiple nodes, 1000 base stations and 300
network gateways. One node is needed for every 250 talk paths in the
network. One or more additional nodes are desirable for redundancy. Each
reciter in a base station provides two voice channels and each gateway a
single voice channel.
To determine the number of nodes required, simply add all available voice
channels, divide by two hundred and fifty and add one:
(Traffic channel reciters x 2) + (Network Gateways)

Number of nodes = +1
250
A network can have up to 20 nodes and a maximum of 250 sites. See

Section 2.1 Network Dimensions for more information on system sizes.
3.1.7 Centralized Call Control
The control node sets up and clears down all calls. Control communications
are with the control node’s logical IP address. This design avoids the
reliability problems experienced in networks that use multicast addressing,
which require careful configuration of routers and switches through the
many hardware and firmware changes over the life of the network.
This does not introduce a single point of failure, because if the control node
fails, another node takes over the logical IP address.
3.1.8 Channel Authorization
Overview Channel authorization is a DMR standard feature that reduces uplink

collisions where, on trunked or conventional channels, radios may press
push-to-talk at the same time. Without channel authorization, only one
talker may be heard, or if both radios are at the same site, they may even
corrupt each others’ transmissions so that no-one is heard. To other radio
users it will sound either like broken up speech or two overs running into
each other, or one talker will simply not be heard.
With channel authorization, when there are multiple call requests, only one
radio gets a go-ahead from the network. The winning radio gives a go-
ahead beep to let the radio user know they have succeeded gaining the
uplink, while other radios give an audible deny signal.
How Channel Radios operate in simplex mode, so once a radio begins transmitting it is
Authorization not possible for the user to hear if someone else may also be talking, and
Works
that they should stop transmitting to avoid a collision.
The channel authorization feature provides a handshake so that radios (that

are enabled for channel authorization) can determine when they have won
the floor.
The floor, in the case of channel authorization, is the collective RF uplink.

Every time a radio user anywhere in the network presses push-to-talk
(PTT), the radio initially transmits only the initial burst - which contains the
identity of the talker. The radio then stops transmitting to listen to the
downlink.
Base stations recognise the initial burst as a reservation request. If the base
station has not already reserved the floor, it does so, and begins forwarding
a stream of the same reservation request to the controller. The controller
repeats the reservation stream back to the base stations so that all radios can
recognise that the floor is reserved, and can know who won the reservation.
If two radios at different sites both succeed in reserving the base station
floors, the controller still only repeats the first stream to arrive from any
base station.
Because the transmitted reservation stream includes the identity of the

originating radio, the winning radio provides a go-ahead beep for the user,
and begins transmitting speech. Losing radios provide a deny beep and do
not transmit.
Channel authorization is not used for all call types:
Does Not Use Channel

Uses Channel Authorization
Authorization
Individual voice calls to consoles and Stun/revive/bar

radios
Group voice calls to consoles and Call alerts

radios
Individual packet data calls Status requests and responses
Group packet data calls Emergency alerts
Encrypted calls Short data messages
Transmit interrupt (with the above call USBD polling

types)
PSTN calls
Notes ■ Good networks with heavy traffic and good coverage particularly
benefit from channel authorization. Networks with less traffic, greater
network delays and significant areas of poor coverage are likely to
benefit less.
■ The Tait network is flexible - the controller allows call overs to use the
authorization handshake (polite) or not (impolite). It is possible to mix
polite and impolite radios in the network, but the benefits of the feature
diminish as the proportion of radios using impolite access increases.
■ Channel authorization does impose a small additional call set-up delay
to complete the authorization handshake. This delay will be more
noticeable as network linking delays increase.
■ In a poor coverage or fading environment, call set-up can take longer if
radios need to time-out and retry when performing the authorization
handshake.
Deployment 1. The DMR network must be operating version 3.38 or later (or
Prerequisites version 4.xx).
2. The DMR base stations must be operating version 3.20 or later.
3. The Tait radios must be operating version 2.28 or later, and have the
channel authorization parameters configured (Trunked > Radio
Calls > Call Options > DMR ‘Channel Authorization’).
If radios have channel authorization enabled without network support (i.e.

running on versions earlier than 3.38), successful PTT operation will
depend on network timing.
Fallback and stand alone operation in the base station does not depend on
the controller. The base station has configuration parameters for channel
authorization for these cases.
Monitoring ■ Checking channel authorization status:

Problems
■ The channel authorization status is displayed on the base station
DMR network connections monitoring screen (Monitor >
Interfaces > DMR network connections > State) for each logical
channel. Traffic channels display either ‘Traffic - auth’ or ‘Traffic
- no auth’.
■ When authorization is not working, radios can talk over other radios:
■ Check the channel authorization configuration for the offending
radio.
■ If the PTT response is unreliable, radio users do not get the go-
ahead. Check that channel authorization is enabled in the
network (any base station, see above).
■ Network delays are wrong:
■ Some radios are impolite (i.e. not enabled for channel
authorization).
3.1.9 Hunting Behavior in Dual Mode and Fallback Mode
The following statements describing hunting behavior in dual mode

(DMR/MPT) systems and fallback mode need to be taken into
consideration when configuring a dual mode system:
■ If vote now messages are used by the network, background hunting (if
enabled) will not happen as it will be overridden by the vote now
messages
The DMR external adjacent site feature can be configured for each site.
There are two types of external adjacent site: either those that are fixed,
as in cell extender sites, or those that are inter-network. For external
adjacent fixed (or cell extender) sites, the external adjacent site informa-
tion will enable radios to vote between the site and the external fixed
site. For external adjacent inter-network sites, the external adjacent site
belongs to an external DMR or MPT-IP network (using an inter-network
connection); and the current network will broadcast information about
this external site (RF number and syscode) to enable radios to vote
between the site and the external inter-network site. For configuration
instructions, see Section 5.16 Configuring External Sites.
■ If voting is enabled, the radio will move to another site (DMR or MPT)
if the current signal is < L2 (default value -94dBm), and the sampled
signal is higher than the radio’s Vote Now Advice Margin
■ If the signal < L0 (default value for high power -113dBm) and there is
loss of service or if the codeword error is high, then the radio will
behave as follows:
a. It will first perform an adjacent channel hunt (this uses the chan-
nels it has learnt from the vote now messages)
b. It will then perform a preferential hunt (based on the channels
defined on the programming application’s hunt channels -
defined in the Hunting Parameters, then on the other channels it
has learnt from the vote now messages as well as on any other
channels that the radio has previously learnt and used for ser-
vice).
■ Background hunting will operate in fallback/failsoft modes, regardless
of the radio configuration
■ If the system for any reason enters fallback mode, Tait radios (TM9300/
TP9300/TP9500 and TM8200) will first perform a preferential hunt in
order to tune into the fallback channel
■ In TM9300/TP9300/TP9500 radios in fallback mode, at the end of each
call the radio will perform a preferential hunt in order to check if the
system is up and running again. This will affect radio behavior as radios
could miss any calls that may happen during the preferential hunt. This
will depend on the size of the hunt list.
In addition, at regular intervals when the system is idle (approximately
every 15 seconds), the radio will perform a background hunt. The radio
could miss any calls that may happen during this period.
■ The TM9300/TP9300/TP9500 (not the TM8200) when in fallback
mode, will display ‘Limited Service’ (if registration BCAST messages
are enabled, which is the default on Tait base stations). If Registration
BCAST is disabled, the radio will not know that the system is in
fallback mode and will not perform a preferential hunt at the end of each
call. It will however, perform a background hunt as configured.
3.1.10 Group Affiliation
The node keeps track of which groups have one or more members at a site,
so that when a group call is made, the call is set up only on those sites where
group members are present.
When a unit affiliates to a group (or multiple groups) the affiliation is one
of two types:
■ Subscription: this is the process by which a radio unit informs the
network of which talk groups are relevant for the said unit for the
purpose of registration-based groups. Standards-based subscription is
analogous with Tait’s existing and proprietary Group Affiliation (also
referred to as RCGA).
■ Attachment: this is slightly different to subscription in that it allows a
network to authorize only certain groups for a radio unit at a particular
site. The unit can then choose to remain at the site, with perhaps no
access to unauthorized groups, or choose to move to a new site for better
service.
The DMR specification did not originally provide a standard mechanism

for affiliating radio units with groups until v1.7.1 of the TS 102 361-4;
since when Talkgroup Subscription and Talkgroup Attachment1 can be
optionally implemented as part of radio registration. As such, Tait’s
original Group Affiliation (created before DMR specification v1.7.1) is
proprietary, but provides a subscription-based affiliation scheme for Tait
DMR radios and nodes.
Tait’s Group Affiliation allows for 16 groups, as opposed to 7 with the

DMR standards-based subscription and attachment schemes.
Group Affiliations Normally the node controller only requires group affiliations from a unit
Required on Site the first time it powers up, or if it changes its groups. The node controller
Move
will remember the groups a unit is in, even when it moves sites, so it will
set up group calls at the appropriate sites.
However, if the group attachment feature is enabled in a unit, the unit will
need to know if its groups are supported at each site it tries to register on,
so that it can select sites based only on where its group calls will still be set
up. This requires the unit to always affiliate when it registers at a new site,
as the acknowledgment report from the node controller is the only way to
inform the unit which groups can be setup at the site.
To enable group attachment in a Tait radio unit, the Group Affiliation

scheme chosen must be set to DMR Standard, and the Hunt on Refused
Affiliation parameter should be enabled via the Fleet Settings > Fleet
Parameters configuration page of the Tait radio’s programming
application.
From release 3.40 of the node WebUI, the Group Affiliations Required on
Site Move parameter has been added to Settings >Network Parameters >
Features.
By default this parameter is disabled, however enabling it will adjust the

general site information broadcast so that the radio knows it must send
talkgroup affiliation information during each registration process, even
when roaming between sites. Enabling it to require group affiliation on site
1. Talkgroup Subscription is fully supported by Tait DMR networks. Talk-

group Attachment has limited support in defining which affiliations will
be rejected.
move will use more control channel bandwidth on every site registration,
so it should only be used if talkgroup attachment is required.
The Subscribers > Group Profile parameters Restrict to Fleet Members and
Restrict Affiliations to Service Area are used by the node controller to
restrict group affiliations. If neither of these parameters are enabled, there
is no point enabling the Group Affiliations Required on Site Move
parameter, as all group affiliations will be allowed.
The Group Affiliations Required on Site Move parameter is only available

if version 1.10.1 or later of the DMR specification is selected in Settings >
Network Parameters > Compliance.
3.1.11 Group Call Handling
In a trunked network, when a radio user presses PTT, the radio does not
simply begin transmitting, as in a conventional system. Instead, it sends a
call request, which the node processes. If the request is approved, the radio
is instructed to tune itself to the frequency pair of a free traffic channel and
to use its timeslot. This happens so quickly that the user can simply press
PTT and begin talking.
calling destination
radio node group
group
voice
requ est [1
, 2]
control
] group
rant [3 voice channel
c ha nnel g c hanne
l
e grant
grou p voic [3]
conversation [5, 6]
call inactivity
timer [7] traffic
tion call te channel
rmina rm
call te inatio
n
The following describes how the trunked network handles a group call.
4. The user presses PTT, causing the radio to send a group voice request
to the control channel.
5. The control channel passes this request on to the node, which carries
out a validation check on it. The call can only proceed if it passes this
check. If it fails, the node sends a call deny message and the radio
beeps accordingly.
6. If there is a free traffic channel, the control channel (and other

control channels at other sites) sends a group voice channel grant
message. If there is no free traffic channel, the call is queued and the
radio emits the corresponding tone.
7. The calling radio and other radios belonging to the group go to the
traffic channel specified in the message. The calling radio can
optionally give ‘go ahead’ beeps to indicate that the call has been set
up.
8. The caller begins talking. The traffic channel receives the call,
repeats it, and sends it to the node.
9. The node sends unicast voice streams to the designated channels at

all the sites where group members are registered.
10. When the user releases PTT, the network behaves differently
depending on its configuration:
■ If the call inactivity timer is set to several seconds or more (it can
be configured to anything between 0 and 60 seconds), the
network provides quasi-transmission trunking. For quasi-
transmission trunking, the inactivity timer must be set to at least
1 second.
■ If it is set to 0 seconds, the network does not time out for
inactivity.
11. If there is quasi-transmission trunking and a group member presses

PTT before the call inactivity timer expires, the radio transmits
directly on the traffic channel.
Quasi-transmission trunking gives very quick channel access, but it
has no mechanism for resolving contention if more than one member
talks at the same time; only one member’s voice will be repeated and
the other member may still be talking, unaware that his voice is not
being heard.
When the call is over, the call inactivity timer expires and the traffic
channels are freed for another call.
The following additional features of group calling are worth noting:

■ Dispatcher voice can be enabled to override voice arriving over RF at a
base station
■ Currently there is no arbitration when two consoles attempt to PTT on
the same talk group. The first in wins every time.
■ The audio delay after a console override (this is the delay between when
the override has stopped and when the original caller’s audio can be
heard again) is less than 1 second (around 600 ms)
■ The network signals when another party is already talking. Radios that
recognize this signal won’t allow the user to transmit. This stops one
user from transmitting when another user at a remote site has already
begun talking.
■ If a radio is turned on or roams onto a site, the network will include it in
an already-running group call, even if that site was not previously
participating in the call.
3.1.12 Roaming
Radios are able to roam from one site to another. At a configurable interval,
control channels send C_BCAST (Vote Now) messages that instruct idle
radios to assess the signal quality of the control channel specified by the
message. If the quality of the control channel is significantly better, the
radio registers with it. Roaming cannot occur in the middle of a call.
Tait recommends that no more than twenty adjacent sites be configured for
each site. These adjacent sites can be internal sites, external inter-network
sites, or external fixed sites. Only the sites nearest in location to the current
control channel should be configured as adjacent in order to maintain
acceptable performance during site re-selection.
Within a network (internal sites), the adjacencies are dynamic, so if the

control channel rotates, the adjacent sites will know about it and will update
the RF number and syscode to the new channel.
Between networks, the external adjacencies can be fixed or dynamic. If

they are fixed, if the control channel number changes (for maintenance or
rotation purposes etc.) then the adjacent site information needs to be
manually updated accordingly, otherwise the wrong information will be
broadcast. If they are dynamic, the adjacent site information is
automatically updated.
For external inter-network adjacent sites, only the site alias is configured
between the networks; using the inter-network connection protocol, the
networks regularly exchange this information, so if the site information
(site alias, RF control channel number, syscode) changes, each network
will receive the updated control channel parameters (which can be viewed
on the WebUI).
Refer to Section 5.16 Configuring External Sites for instructions on setting

up external adjacent sites.
3.1.13 Adaptive Vote Now
This is a Tait-customized vote now feature where the vote now offset
threshold and vote now margin can be adjusted per site. By setting these
levels you effectively configure how to either make radio units hold on to
one site for as long as possible, or roam to another site faster. This feature
is for use on those sites that have better capacity or higher importance than
others; where it is beneficial for the radio units to stay on the site for as long
as possible.
The adjustable settings are Vote Now Threshold Offset and Vote Now
Advice Margin. The vote now threshold applies an offset of the chosen
value to the radios pre-programmed L2 level. The selected vote now advice
margin, on the other hand, is an absolute value that replaces the advice
margin value pre-programmed into the radio for that voting instance. These
adjustable settings are not permanent in the radios, and are learned and used
per vote now request. If Non-preferred Site is selected as the setting for the
Vote Now Threshold Offset or Vote Now Advice Margin parameters, this
means that the radio will only use its programmed values.
When Tait Adaptive Vote Now is enabled, a manufacturer specific

broadcast is sent (i.e. Tait Adaptive Vote Now) as well as a DMR standard
vote now broadcast. The Tait broadcast is sent first, so that radios that
support the feature will use the Adaptive Vote Now feature. The DMR
standard broadcast is sent second, for any radios that do not support the Tait
Adaptive Vote Now feature.
This feature requires TN9391 Node Controller version 2.20.06 and

TP9300/TM9300 DMR radios version 2.18.02 or later.
Feature Example In the following diagram, all radios are currently registered at Site A, and
all are configured with an ‘RSSI Level for L2 (Hunt)’ parameter set to
-80dBm, and a Vote Now Advice Margin of 6dB configured via radio
programming.
This means that when Adaptive Vote Now is not enabled, or the adaptive
vote now parameters are set to ‘Non-preferred site’, the current control
channel signal received by all radios at Site A needs to be less than -80dBm
before the radio will consider roaming via Vote Now, and the candidate
control channel must be 6dB greater than the currently selected control
channel.
Site A
Adaptive vote now parameters:
• Vote now threshold offset = -15dB
• Vote now advice margin = +9dB
Site C
Radio
One
Radio
Three
Radio
Two
Site B

■ When the adaptive vote now parameter ‘Vote Now Threshold Offset’ at
Site A is set to -15dB, and the adaptive vote now feature is enabled, the
radios will adjust their L2 for each vote to -95dBm. This is the ‘RSSI
Level for L2 (Hunt)’ parameter programmed into the radio plus the
broadcast ‘Vote Now Threshold Offset’ parameter
(-80 + -15 = -95dBm). This means that the current control channel
received by radios on Site A needs to be less than -95dBm before the
radio will consider roaming via Vote Now. If the L2 signal strength
validation is successful, the candidate control channel being sampled at
Site B and Site C via Vote Now would also have to be +9dB stronger
than the signal received from site A for the radio to move, due to
Site A’s advertised Vote Now Advice Margin.
■ If a radio registered on Site B were to be sampling Site A via vote now,
then the applied L2 and Vote Now Advice Margin for each vote would
be -92dBm and +3dB respectively. This is the ‘RSSI Level for L2
(Hunt)’ parameter programmed into the radio plus the ‘Vote Now
Threshold Offset’ parameter (-80 + -12 = -92dBm). This means That the
current signal strength from Site B would need to be less than -92dBm,
and Site A would have to be +3dB stronger in signal strength than the
currently received Site B for the radio to move.
■ If a radio registered on Site C were to be sampling Site A via vote now,
then the applied L2 and Vote Now Advice Margin for each vote would
be -90dBm and +3dB respectively.
3.1.14 Failure Tolerance
The Tait DMR network is designed for maximum system availability.

Its architecture gives it a high tolerance of failure. Single points of failure
can be avoided. If a network element fails, an alarm is raised on the NMS.
The following table details the effect of a failure:
If this fails... Then...

Node If there is only a single node, at each site a base station can
be configured to take over and exercise control channel and
basic node functionsa. Local individual and group calls can
be made. Short data, status messages, supplementary
services and packet data are not supported.
If the control node fails, another node at a different
geographical location automatically takes over
If one of the switching nodes fails, the control node
distributes the work among the other switching nodes
SNMP manager If there is only one SNMP manager, central monitoring of the
server network is not available. Maintainers can still monitor
individual nodes and base stations. (Note: The network can
be provisioned with a second SNMP manager; base
stations, gateways and node computers can be configured
to send traps to three different IP addresses.)
Call record server If there is a backup server, it will take over and little
disruption should occur.
If there is no redundancy, when the application restarts, it
reloads the call records from the moment before the failure
occurred.
Call records are kept by the node for at least three months,
allowing a reasonable period for the computer to be
repaired, before information is lost.
Site-node At the isolated site, one base station takes over, functioning
communications as control channel and “network controller”. It provides
signaling messages for the control channel to transmit and it
can handle local (not intersite) individual and group calls.
Short data, status messages, supplementary services and
packet data are not supported.
Node-node The result depends on the network topology. The network
communications could turn into two independent networks, each with a
control node. To mitigate this, we recommend grouping
nodes at particular locations. However, at least two
locations are needed for geographical redundancy.
All but one base The remaining operational base station uses TDMA to
station at a site provide the control channel and a single traffic channel.
Control channel The network automatically takes the channel out of service
and raises an alarm. The traffic channel with the lowest
channel number takes over the role of control channel.
(Any traffic channel can take over.) Channel capacity is
reduced by two (or four, if a full subrack fails).
If this fails... Then...
Alternate channel The control channel has failed and a new control channel
will take over:
■ If the new control channel has its alternate channel
enabled, then polling will continue on the new alternate
channel, unless it is the only channel left at the site
configured for traffic channel use, in which case the
node will leave it available for traffic channel calls, and
not use it for polling
■ If only one alternate channel has been configured at the
site, polling will continue on the control channel, but only
for radios that have polling enabled on both the control
and alternate channels
Traffic channel Channel capacity is reduced by two (or four, if a full subrack
fails). The network automatically takes the RF channel(s)
out of service.
Gateway The devices attached to the gateway lose service. To
mitigate this, multiple network gateways may be used.
a. See Section 3.1.15 Single Site (DMR Access) or Fallback Mode.
3.1.15 Single Site (DMR Access) or Fallback Mode
Single site (DMR Access) is a DMR single site system where the base
station itself acts as a standalone node.
As a standalone node, the base station operates like a DMR trunking

controller with limited functionality (see below), controlling a maximum of
four physical channels.
Similarly, in a multi-site system with a single node (if it should fail), at each
site a base station takes over, entering fallback mode and exercising control
channel and basic node functions as follows:
■ Status messages (on the control channel)
■ Individual calls (OACSU/FOACSU)
■ Group calls
■ Emergency calls (with pre-emption)2
However, when in single site (a DMR Access system) or in fallback mode,

the base station does not support:
■ Short data messages
■ DMR packet data
■ Console interfaces
■ Voice recorder interfaces
■ PSTN calls
2. Whilst emergency calls (with pre-emption) are supported in single site/

fallback mode, the specific ‘Emergency Group Override’ feature is not.
In fallback mode, each site sends a ‘limited connectivity’ message to the
radios at the site, which will then display ‘Limited Service’. The radios will
also periodically perform a background hunt to find another control
channel when in fallback mode. Since radios will spend less time listening
to the confirmed control channel, it is possible that important messages
may be missed.
In standalone mode, the site does NOT send a ‘limited connectivity’

message to the radios, they just return to the confirmed control channel (of
the standalone site) after each call.
Base station Single site trunking and trunked fallback require one base station at a site
operation in single to become a controller and the site’s other base stations to operate as traffic
site or fallback
mode channels.
■ The controller operates a control channel that allows radios to make
calls
■ The controller does not have a registration database. Any radio can
request registration and be granted it.
■ The controller hands off call requests to traffic channels which then
repeat the radio signal
■ Base stations at each site co-ordinate roles using the site discovery
protocol (set in the base station user interface at Configure > Network
interfaces > DMR network > Site)
Which base station becomes the controller is determined by the Node

priority configuration value (Configure > Network Interfaces > DMR
trunking > Site > Node priority). The lower the number the higher the
priority. The value range is 200 to 255.
Each base station user interface shows the statuses of other channels at the
same site at Monitor > Network > DMR site status.
3.1.16 Call Amalgamation
The call amalgamation feature enables a radio to join an existing group call.
A call record will be created for the radio to show that it has been
amalgamated into an existing group call, but the group call’s original call
record remains unchanged.
The following examples show how the call amalgamation feature works.
Group Calls The call amalgamation feature allows a radio that has been in another call
to join a group call that was previously set up without it, simply by calling
the group. It can also be used to rejoin a group call if the radio has
previously left the call but wants to go back to it, providing it was not the
originator of the call.
Call amalgamation is also used to join to an existing group call when the
radio has not received or is ignoring GTC messages.
Notice For emergency calls, call amalgamation will only happen if
the radio to be amalgamated into the group call has used the same pri-
ority, when calling the group, as the existing call. For non emergency
calls, call amalgamation will work even if different priorities are used.
For example: if a normal group call is in progress and a user calls this
group as an emergency call, then the original group call is closed and a
new emergency priority call is established.
Individual Calls If a radio that has been programmed to allow individual call override is in
an individual call, it can be amalgamated into a group call set up on a
different traffic channel. The individual call it was in will still be active,
and will only clear either:
■ At the end of the activity timeout
■ At the end of the call duration timeout
■ Or by the other party remaining in the call
If the radio it was in the individual call with has the same override settings
enabled and is also amalgamated into the group call, the original individual
call will again still be active until it times out, otherwise it will be left in the
original individual call.
Telephone Calls Telephone calls cannot be amalgamated.
3.1.17 Direct Mode
Radio users outside the radio coverage area of the network, or working in
a team at a local site, may wish to operate in digital simplex mode (or direct
mode), communicating directly between their radios and bypassing the
network. Radios that are programmed to operate on a single frequency are
automatically set up in digital simplex mode. A number of services that are
supported in the wide area solutions are also supported in direct mode.
These include talkgroups, individual calls, GPS location updates, status,
etc.
3.1.18 Security Features
Protected Access Radio access to the services of the network is controlled through
to Network Services administrator configuration of the node. Only radios using numbers that
have been declared to the node can use the network. A radio can also be
restricted to operation only at selected sites. A radio must first register on
the network before using its services.
To prevent radios from usurping the identity of a legitimate radio, the node
can ask radios to authenticate themselves when they register.
The authentication process is based on RC4 encryption (a popular
encryption algorithm commonly used to protect Internet and wireless
traffic). Radios have a 56-bit authentication key. The administrator can bar
any radio from using the network.
Protected Access The nodes and base stations in a DMR network have various levels of
to Network protection against unauthorized access. Browser communications with
Infrastructure
these elements are encrypted using HTTPS. Users can be given different
levels of access. They must log in with a unique name and password.
Logs provide an audit trail that indicates the actions of each user.
Private Digital transmissions by their very nature ensure a certain level of privacy.
Communications Eavesdropping requires the use of DMR-capable scanners.
Some network users may want to increase that level of privacy through the
use of encryption. Tait can offer DES and ARC4 encryption.
3.1.19 Registration/Authentication
Before a radio can use the network, it must be registered and authenticated.
The node maintains a database of registered radios and their locations.
An authentication request is only accepted if the node knows about the
radio and the radio is at a site where it is authorized to have service.
Through authentication, the radio declares its location to the network as it
moves around. This permits calls to be connected without searching
through the network for the called party.
The node can optionally demand an authentication check in response to an

authentication request. This prevents unauthorized radios from usurping
the identity of an existing radio on the network.
3.1.20 Background Checks
In certain situations, it is possible for the node to lose track of a unit.
During a normal call setup, if the radio is not at the site where it is
registered, the node will hunt for the radio. When it finds the radio, the call
will setup, and the radio’s registration record will be updated.
However, with USBD AVL polling, the radio is only ever polled at the
control channel and site where it is registered, regardless of whether it is
still there or not. If AVL polling is the only interaction the node has with a
unit, the polls could potentially fail for a long period of time if the
registration record is out-of-date.
Background polls that are designed to try and find a potentially lost unit can
be enabled. The background checks work as follows:
■ If a registered radio fails to respond to a call setup or poll, it will be
added to a queue of radios to be background polled
■ By default, every 10 seconds, one radio in the queue will be sent an
availability check in the background to try and find the radio (system
poll period)
■ If the radio responds, the registration record is updated and the radio is
removed from the queue
■ If the radio does not respond, it will be added back to the queue to be
polled again at a later time (minimum unit poll period)
■ Background polling for a unit will also stop if other activity by the radio
is detected, such as other call setups
The background check parameter settings are configured in Settings >

Network Parameters > Background Checks.
3.1.21 Encryption
Tait DMR networks (also TM9300 and TP9300/TP9500 radios) support the
following encryption types3:
■ DES56
■ ARC4
■ AES 128
■ AES 256
The Tait radios that are loaded with DES, AES or ARC4 encryption keys
are very secure. The encrypted keys in the radios cannot be read. DMR
nodes using DES, AES or ARC4 encryption keys are also very secure. The
encrypted keys are securely stored in the node database. However Tait
programming applications do allow for the configuration files containing
the encryption keys to be backed up, so it is very important to store these
files in a secure location.
The DMR node webUI and programming applications for the TM9300 and
TP9300/TP9500 radios allow for the created keys to be copied/pasted,
allowing for ease of configuration. Note that on the node webUI, this can
only be done when the key is being entered, as after this the key is not
available to be read again.
With AES encryption, the DMR node webUI and programming

applications for the TM9300 and TP9300/TP9500 radios allow you to
generate the encryption key from a passphrase. The same passphrase used
in each application will generate the same AES key.
With DES encryption, a passphrase can be used to generate an encryption

key in the programming applications for the TM9300 and TP9300/TP9500
radios, but not in the DMR node webUI.
Encryption is available for voice calls involving external interfaces such as

calls to MPT gateways, phones, SIP, DIP, and AIS. For voice calls from
external interfaces, voice will be encrypted according to the encryption
profile of the called unit or group. Voice calls from the DMR network to an
external interface will always be decrypted - as long as the key for that
stream is known (i.e. it is configured on the node).
3. AES encryption is only available on certain DMR releases.
Notice Encryption stops in the node controller for all external inter-
faces.
Encryption end point

Encryption end point for
external interfaces
Node Dispatch console
Encrypted voice call

– over the air
Encrypted calls between

node and external
interfaces are decrypted
Base station Encrypted calls

between receiving
base station, node
and transmitting Voice recorder
base station
Base station
Encrypted voice call

– over the air
Encryption end point
For radio-to-radio or radio-to-group calls encryption is end-to-end, and

voice is encrypted/decrypted by the radios according to the encryption
profile for the called unit or group. The DMR network does not alter the
encryption status for these types of call.
A radio configured with an encryption key can receive clear voice from a
radio without encryption. Disabling encryption via a function key or menu
on a radio only affects the transmitter, the radio will still decrypt calls.
There are two instances where encryption is not supported:

■ Data calls
■ DIP patched voice calls
3.1.22 Remote Access
The network can be set up with secure remote access for use by Tait support
staff or by on-call network administrators working from home. (Tait offers
several tiers of service contract that can provide remote technical support
of the network.) For example, the remote PC can use a VPN (Virtual
Private Network) connection over the public Internet to an on-site
administrator PC and the Microsoft Remote Desktop protocol so that a
Tait Enable client can log in to base stations.
3.1.23 IP Data
The IP data feature provides a generic IP data service that is able to pass IP
data between radios and a data server that is IP-connected to the network.
It provides the foundation that enables clients and partners to deliver data
applications and for network users to access them across the network.
Licenses are required for the DMR node controller and radios to operate IP
data.
Control Channel
• Network registration
• IP address registration PPP
• Data channel request/
grant
PC Application
Traffic Channel Mobile IP

• Packet data Foreign Agent
transfer
Node Mobile IP Home Agent
database
Data Server
IP data uses mobile IP4. This protocol allows the radios to appear like other
IP devices on the IP network. Standard routing protocols and techniques
can be used to maintain connectivity to them.
For a radio to use IP data, the use of data must be enabled and an IP address
must be assigned in its configuration. When a radio registers with the DMR
network, it also registers its IP address. The node establishes a session with
the mobile IP home agent (generally a telephony router logically close to
the node). Radios can roam to other sites and still maintain the same mobile
IP session.
IP data is carried over the traffic channels. The traffic channels can be
configured with different priorities, depending on whether voice or data is
more important. Call timers are also configurable. Narrow band radio
channels provide a low bandwidth IP link, and applications using them will
get the best performance by using application protocols specifically
designed for half-duplex low bandwidth links.
4. DMR mobile IP requires the use of NTP (see “Network Time Protocol” on
page 67)
3.1.24 Location
Mark a Point of This feature allows a radio user to press a button which sends their current
Interest location to a dispatcher.
For example, a train driver might see something on the tracks or by the side
of the train that should be reported to the dispatcher. Depending on the
incident, a dispatcher may need to alert the authorities and tell them where
it happened.
This used to be done using a voice call, which depended on the radio user
getting through to a dispatcher at the right time. Now, with the press of one
button, the AIS call-alert service (defined in AIS1.0) is used to pass the
location to the dispatcher immediately.
3.1.25 Transmit Interrupt
The Transmit Interrupt feature is key to further enhancing worker safety on

the Tait DMR network. Critical communications related to the safety of
personnel in the field are guaranteed to be heard by all intended parties,
including those that may be transmitting.
From an end-user perspective this feature is designed to be transparent, and

will enable field supervisors or dispatchers to be certain to reach desired
groups of users, whatever the system usage circumstances are.
DMR Transmit Interrupt is a standard-based feature currently defined in

the DMR Trunking Protocol specification (ETSI DMR Part 4); capable of
remotely de-keying a radio that is transmitting voice.
Compliance Transmit interrupt is only available when the DMR specification parameter
in Settings > Network Parameters > Compliance is configured as version
1.8.1 or later.
Functional In its simplest form, the Transmit Interrupt feature relies on two
Overview mechanisms over the air interface:
1. In the inbound direction (radio unit initiator side):

■ A transmit interrupt request, in the form of a status message with
its value set to 125, is sent over the control channel (the radio unit
has to temporarily leave the traffic channel)
■ The node acknowledges the request before the transmit interrupt
timer (set in the radio’s configuration) starts, and before any RC
commands are sent.
2. In the outbound direction (radio unit being interrupted):

■ The transmitting radio unit continuously checks the embedded
outbound reverse channel (RC) in the adjacent TDMA slot for a
transmit interrupt command (every 60ms for fast mode, 360ms
for standard mode. Standard mode will typically be used if third
party radios are also used in the infrastructure.)
■ The network infrastructure sends a cease transmission command/
request via an embedded outbound reverse channel (RC) burst on
the adjacent TDMA slot
■ The transmitting radio unit receives and decodes the cease
transmission command/request and stops transmitting
Depending on the pre-emption type, the interrupted radio will either:

■ Stay on the current traffic channel, leaving the floor to the
interrupting radio (floor pre-emption)
or
■ Leave the call and revert back to the control channel if the call is
cleared due to a priority channel resource request (resource pre-
emption)
Floor pre-emption The floor pre-emption type applies to voice transmissions using the
message trunking mode of operation only. In this mode, the same call stays
allocated to a traffic channel resource for a given duration which allows
parties to transmit voice in sequences; those are commonly called ‘overs’.
Note that the advantages of message trunking are:

■ Security of maintaining the same channel resource. Consequently a lot
of emergency calls on systems are made using message based trunking.
■ Comfort of conversation. Participants to group calls and individual calls
have swift access to the voice channel and can react with little signaling
overhead, resulting in an efficient conversation.
With transmit interrupt, a participant to the call that is configured to allow

its transmissions to interrupt other user transmissions can ‘steal the floor’
(or shorten an over) of an interruptible talker (a user with a radio unit
configured to allows its transmissions to be interrupted).
Notice In transmission-based trunking mode, a new radio resource is

allocated for each transmission (and released at the end of the transmis-
sion), effectively meaning that each transmission is actually a new call.
In this case, the resource pre-emption type applies (see below).
Resource pre- This type of pre-emption clears an active call to free an occupied radio
emption resource where another call with higher importance has to be made.
The following table outlines scenarios where the Transmit Interrupt feature
is required:
Use case Use case description Notes
User floor pre- Radio user wants to interrupt In an on-going call, a radio
emption of an the current transmitting radio user with pre-emption
on-going voice and take the floor to talk privilege can interrupt an
call interruptible radio user and
talk to all talkgroup members,
or in an individual call, to the
other user
Dispatcher floor A dispatcher user wants to In an on-going call, a

pre-emption of interrupt the currently dispatcher with pre-emption
an on-going transmitting radio user and privilege can interrupt an
voice call take the floor to talk interruptible radio user and
talk to all talkgroup members,
or in an individual call, to the
other user
Emergency An emergency call may be When an emergency call is

radio resource initiated requiring an occupied initiated, the system will clear
pre-emption channel to be freed to necessary call(s) to get the
establish the call radio resource(s) to establish
the emergency call on all the
required sites
All Call radio An ‘All Call’ broadcast must Node only feature. The
resource / floor stop everyone talking so that network will use transmit
pre-emption for everyone can hear the interrupt to stop the
voice calls announcement transmitting parties and
eventually free up required
radio resources.
Ambient A dispatcher user wants to Node only feature. The

listening service clear an ALS call. This feature network will use transmit
(ALS) call clear is only available to dispatchers interrupt when an ALS call is
down using external infrastructure cleared by a dispatcher.
interfaces (DIP, AIS…)
Dispatcher Currently, a dispatcher cannot Node internal feature to

force call clear force a call to be cleared if a enforce complete call clear
radio user is still transmitting. down from a dispatcher
With transmit interrupt, the
dispatcher can now enforce
calls to be completely cleared
down, thus optimizing
operations and radio resource
usage.
Maximum call Contention in the network can Node internal feature to

time clear down occur when a radio user starts enforce complete call clear
transmitting close to the end of down when call time expires.
a call. Transmit interrupt Among other contention
allows the network to apply scenarios, the stop/mute issue
consistent call clears when the will be avoided.
maximum call duration has
been reached.
Use case Use case description Notes
Priority/ Radios are required to stop Node only feature. The

emergency transmitting and listen to network will use the feature to
group override channel grant announcements stop transmitting parties so
for group calls that radios can join group
calls, if required.
Refer to Section 6.20 Adding SIP Lines to Outgoing Group Calls for
configuration instructions.
3.1.26 All Ident Calls
This section describes how All Ident calls work in Tait TN9300 DMR
trunked networks.
There are three types of All Ident call defined in the DMR standards:
■ Local All Ident calls - ALLMSIDL (0xFFFFD)
■ System wide All Ident calls - ALLMSID (0xFFFFF)
■ Subset of system wide All Ident calls - ALLMSIDZ (0xFFFFE)
The following applies to Tait DMR trunked All Ident calls:

■ All Ident calls are always broadcast calls
■ System wide All Ident calls are supported by all numbering schemes
■ Only radios using the DMR numbering scheme support the local and
subset of system wide All Ident call dialed strings
■ System wide All Ident calls and the subset of system wide All Ident calls
are converted to local All Ident calls
■ All Ident calls use the call timers (call duration, inactivity, call answer
timeout) of the caller’s unit profile. There is no group profile option for
All Ident calls.
Local All Ident Calls A local All Ident call is defined as one that is broadcast to all of the radios
- ALLMSIDL registered at the same site as the calling party. The following table
(0xFFFFD)
describes how they are handled in Tait DMR trunked networks.
Supported in Tait DMR

Description Dialed String
Trunked
High Priority All Ident Call *1961# Yes
Emergency All Ident Call *1962# Yes
Reserved *1963# No - Radio displays “Number

not obtainable”
Emergency Data All Ident Call *1964# Yes
Short Data All Ident Call *1965# No - Radio displays “Request

denied”
Normal All Ident Call *1967# Yes
Note that:
■ The dialed string is only supported by radios using the DMR numbering
scheme
■ In the call records, the called party is correctly identified as ALLMSIDL
■ All local All Ident calls are broadcast calls, and have the correct priority
flags
System Wide All A system wide All Ident call is defined as one that is broadcast to all of the
Calls - ALLMSID radios registered at every site in the network. The following table describes
(0xFFFFF)
how they are handled in Tait DMR trunked networks.
Description Dialed String Supported in DMR Trunked
High Priority All Ident Call *1981# Yes - but as local All Ident call
Emergency All Ident Call *1982# Yes - but as local All Ident call
Reserved *1983# N/A - Node sets up the call as

“High Priority Data All Ident
Call”
Emergency Data All Ident Call *1984# Yes - but as local All Ident call

denied”
Normal All Ident Call *1987# Yes - but as local All Ident call
Note that:
■ The dialed string is supported by radios using any numbering scheme
■ In the call records, the called party is correctly identified as ALLMSID,
however the calls are set up as local All Ident calls (single site only)
flags
Subset of System This subset of system wide All Ident calls is defined as calls that are
All Calls - broadcast to all of the radios registered at every site in the network. The
ALLMSIDZ
(0xFFFFE) following table describes how they are handled in Tait DMR trunked
networks.
Description Dialed String Supported in DMR Trunked
High Priority All Ident Call *1971# Yes - but as local All Ident call
Emergency All Ident Call *1972# Yes - but as local All Ident call
Reserved *1973# No - Radio displays “Number

not obtainable”
Emergency Data All Ident Call *1974# Yes - but as local All Ident call

denied”
Normal All Ident Call *1977# Yes - but as local All Ident call
Note that:
■ The dialed string is only supported by radios using the DMR numbering
scheme
■ In the call records, the called party is correctly identified as
ALLMSIDZ, however the calls are set up as local All Ident calls (single
site only)
flags
3.1.27 Fast Polling
Fast polling combines the USBD polling service and TSCCAS features of
the DMR Standard to provide a dedicated logical channel for location
services.
The advantages of the fast polling service include:

■ USBD poll/response transactions are more efficient than traditional
methods for AVL and typically offer twice the on-air capacity
■ Increased polling capacity of up to 1000 location polls per minute per
alternate channel; where there are dual control channels at a site, each
control channel can be configured with an alternate channel for high
capacity polling services, enabling up to 2000 location polls per minute
■ For radio units that are resident on a site supporting fast polling, and that
are able to receive and respond to USBD poll requests, the service
provides deterministic and sustainable performance regardless of
control channel load
■ Radio units need not leave the control channel to monitor poll requests,
as this service operates over the same physical frequency as the control
channel
■ Control channel loading is minimized; thereby maintaining best
possible performance for call service initiation
■ As radio units do not need to leave the control channel to monitor poll
requests, and because the USBD response is a single slot of data, fast
polling offers best user experience for mission critical voice and
location services
It should be noted that this feature requires an additional logical channel

(adjacent slot of control channel) that is therefore not available for use as a
traffic channel for standard call services.
TSCCAS support can be selectively enabled for each control channel,

offering maximum network flexibility. This allows busy sites with
sufficient resources (i.e. dual control channels) to benefit from up to two
dedicated fast polling alternate channels, whereas sites with little resource
that may only provide a fill-in service could simply use the USBD poll/
response over the control channel. Sites using USBD polling over alternate
channels can accommodate up to approximately 16 polls per second, or
1,000 polls per minute per alternate channel (compared to up to 4 polls per
second for USBD on the control channel, if it is not busy, and up to 2 polls
per second when using UDTs on the control channel).
Subscribing to the fast polling service can be achieved through supporting

AVL APIs, or through the node WebUI. This includes the rate at which a
radio must be polled. In the event that the alternate channel becomes
saturated, the rate(s) of polling across all radios will reduce incrementally
until such time as the channel is no longer saturated. Rates will increase
incrementally as bandwidth on the channel allows, until such time as the
subscribed rates can, again, be met (as the density of terminals on the
alternate channel reduces).
Consideration should be given to channel redundancy at a site, as a fast

polling alternate channel will remain active, along with the control channel,
in the event of channel failures at a site.
All location polls via USBD (whether on a control channel or alternate

channel) are maintained in a database on the node and are made available
to the following interfaces; the node will reformat this data to meet the
needs of the format supported by an API, meaning a loss of data or
precision may result:
■ DIP
■ LIP
■ Monitoring Services API
1000 location polls per minute
Sites supporting
USBD over TSCCAS
avl
AVL Client
4 location polls per second
Sites supporting
USBD over CC
Up to 10,000 location polls across network
The DMR Standard provides for additional service types over the USBD
polling service, which will be added in future releases. However, the only
service type supported presently is LIP for location polling.
Refer to Section 5.17 Configuring an Alternate Channel for instructions on
configuring an alternate channel for USBD polling.
3.1.28 Jammed Channel Detection
A channel that is subject to intermittent interference can be flagged as

enabled for ‘Inhibit if Jammed’. If this parameter is enabled, the node will
inhibit the channel if it is being jammed by other signals. If the channel’s
receiver gate unmutes over a period of time when it is not in a call, the node
concludes that it is being jammed.
If the control channel is determined to be jammed, the traffic channel with

the lowest channel number takes over the role of control channel. (Any
traffic channel can take over.)
The following factors will affect control channel reversion times:
1. Control channel switchover time:

This is the amount of time from when interference is detected to
when another channel takes over as the control channel, and is usu-
ally between 600 to 700 milliseconds (i.e. there is no control channel
in operation for this amount of time).
2. Control channel resumption:

Once interference on the original control channel is no longer
detected, it will resume operation as the control channel. The time
this will take depends on the following:
■ The base station’s RF interference > Off time parameter
■ The node controller’s configuration file Jammed channel hang
time parameter (default is set to 30 seconds)
■ The processing time the node takes to switch back to the original
control channel
Depending on these factors, control channel resumption may take
between 31 to 34 seconds. Note that the amount of time during
which there is no control channel in operation is still only approxi-
mately 600 to 700 milliseconds as above, i.e. the control channel
switchover time.
3. The time the radios take to leave the current control channel and hunt
for and register on the new control channel when there is a
switchover.
3.1.29 Shared Channel Operation
This feature can be used on networks where dedicated frequencies may be

limited, and license provisions may require a shared frequency channel to
only be occupied for a limited time. It prevents a channel from being
selected if one of its frequencies is in use by another network.
Shared channel operation has two levels of interference detection. With
level 1 monitoring, the base station monitors its own uplink for
interference, and in level 2 monitoring, a separate monitor receiver is used
as well, to monitor the downlink frequency for interference.
Enable uplink or downlink monitoring in the base stations as needed by

your channel plan. If both are required, the base stations combine the level
1 and level 2 monitoring into a single signal to send to the node. The node
will then allocate channel resource depending on interference detection.
Points to note:
■ A mobile radio or a reciter can be used as a monitor receiver. The
monitor receiver must be sufficiently well isolated from the base
station’s transmissions that its receiver is not damaged. Ensure that the
RF site design ensures sufficient RF isolation between the base station
output and monitor receiver input.
■ Control channels operate continuously, so do not support shared
channel operation.
■ Channel groups do support this feature. The channel group manager
aggregates the interference information for the call manager, which
makes the appropriate call allocation decisions.
For full feature configuration details, refer to the relevant base station
documentation and help files.
Refer to Level 2 Monitoring for Shared Channel Operation in DMR Tier 3

Systems (TN-3077-AN) for a full feature description. Contact Tait
Technical Support for feature implementation assistance.
3.2 Interfaces
The Tait DMR trunked network supports a number of interface types for
connecting a variety of equipment such as dispatch consoles, telephone
exchanges and other radio networks.
3.2.1 Tait TN9271 Analog Gateway and G.711 Connector
Note that the TN8271 network gateway has reached end-of-life, and
whilst currently supported, is no longer available. The TN9271 analog
gateway and G.711 connector application replace TN8271 network
gateway functionality.
The TN9271 analog gateway is a network gateway that provides an analog

interface to a network to allow interconnection to external devices such as
analog dispatch consoles and voice recorders, IP telephony gateways, and
other radio networks. One TN9271 analog gateway module is required for
each voice stream.
Up to four TN9271 analog gateway modules can be housed in a 4U
subrack, together with a PMU.
The TN9271 analog gateway converts the analog 4-wire audio to RTP VoIP
and vice versa. The RTP VoIP is used by TaitNet MPT-IP and DMR
networks. The TN9271 analog gateway is compatible with either type of
network without needing any special configuration (such as firmware
changes).
The TN9271 analog gateway WebUI also allows remote real-time

monitoring of several aspects of system performance. These include the
status of the analog audio line and E&M lines, the operational status of the
gateway itself, and network performance parameters.
The TN9271 analog gateway connects to the G.711 connector, an

application that can reside on a node controller or TN9500 server. The
G.711 connector converts AMBE to G.711 and RTP VoIP to G.711. It is
installed using the administration application, and, like the TN9271, can be
monitored and configured through a WebUI.
The following diagram illustrates the various connection options that are
available in a DMR network using the TN9271 analog gateway and/or the
G.711 connector. Note that AMBE is vocoded digital audio in the same
format as the DMR network's air interface, G.711 is un-vocoded PCM
(pulse code modulation) digital audio, and the balanced audio signal is
analog. The TN9271 analog gateway provides the electrical interface and
the G.711 connector provides the vocoder.
Analog balanced
AMBE console Other networks audio equipment
Digital AMBE
connected
equipment
Analog base station or
Balanced audio donor radio
AMBE
G.711
connector*
AMBE G.711
TN9300 node Analog console

Base station TN9271 analog gateways
G.711
Voice recorder
Digital G.711
connected
* G.711 connectors can
equipment be located on TN9300 or
Other networks Voice recorder FxO/FxS
Digital console SIP phone TN9500 servers
For information on setting up a conventional line using the G.711

Connector and TN8271 Analog gateway, refer to TN-3303 Conventional
Line Interface Integration with the G.711 Connector and TN9271 Analog
Gateway.
3.2.2 Dispatch Equipment
The flexible and capable DMR network architecture is able to connect to a

variety of modern and legacy dispatch equipment.
The following dispatch interfaces are supported:

■ Application Interface Standard (AIS). This is a non-proprietary, all-
digital IP interface based on the widely-used SIP (Session Initiation
Protocol) but adding dispatch-specific enhancements or ‘extensions’ for
setting up, modifying and ending dispatch calls5. Voice is sent and
received as Real-Time Transport Protocol (RTP) packets. The Tait
implementation of AIS only supports the AMBE+2 speech encoding
scheme and so this must be supported by any dispatch equipment
connecting to Tait AIS. From v3.44 / v4.44, the node and G.711
connector allow AIS consoles to send/receive G.711 audio, with the
transcoding services being provided by the node/G.711 connector (as
per Section 3.2.8 Interface Connectivity Options).
■ MAP27 (Mobile Access Protocol for MPT 1327 equipment) and DIP
(the Tait Dispatcher Interface Protocol). These legacy protocols are only
recommended for use with existing dispatch equipment that already
supports them.
LAN PRIVATE IP NETWORK
AIS (call setup) IP switch

AMBE+2 (audio)
high availability nodes
dispatch with AMBE+2
Tait CMD (Control, Manage, Dispatch) is a completely integrated and

supported Tait system solution, with direct network connection options that
do not require any server or gateway equipment.
Each Tait CMD has an audio connection and a control connection to the
control node of the trunked network. If the Tait CMDs are remotely
located, they must be connected to the node via routers. Tait CMDs can also
be used as a dispatch solution in systems where different trunked networks
are connected together via the TN9500 Inter-Network Gateway.
Computers running the Tait CMD application need to be on a static IP

address; if the IP address changes it will invalidate both the license and the
network gateway address.
A DVSI 3000 dongle is required for transcoding G.711 to/from AMBE.
5. AIS consoles cannot initiate telephone calls (even with diversions in

place).
Tait has also partnered with Avtec, Omnitronics and Zetron to offer digital
dispatch consoles that can be interfaced to Tait TN9300 networks.
3.2.3 Telephone Interconnect
The Tait DMR network can support direct communications between radios
and external telephones through the PSTN. It also supports
communications between radios and private telephone extensions through
a switchboard (PBX), without dispatcher assistance (although dispatch
equipment can also automatically or manually patch telephone calls
through to radios and vice versa.)
Note that in telephone calls (from groups or individuals) the phone user
does not receive any audio indication that their call has been connected.
In addition, once the call has connected, if VOX detection has been
enabled, failing to speak will cause the call to timeout (due to the lack
of VOX detection).
Interfacing with SIP The Tait DMR network can interface directly to a SIP-enabled PABX via
phones an IP connection. The control path goes directly to the node but the voice
path goes through a network gateway or G.711 connector for transcoding.
A network gateway or G.711 connector is required for each PABX voice
path for translating between the DMR AMBE+2 and PABX G.711 voice
streams.
eg PABX/PSTN
PBX
interfaces to telephony
equipment SIP device
SIP over IP
Network Gateway(s)
SIP over IP
IP switch
Node(s)
Private IP Network
Other third party SIP endpoint devices can be connected to the DMR
network, allowing radios to make or receive calls to/from these devices.
The ETC CS-74 (SIP device), shown in the diagram, is a cost-effective
SIP-based console that can support up to four concurrent group calls at a
time.
Network Gateway Telephone networks provide continuous audio signal, so a VOX (voice
VOX operated switch) is used to detect the presence of speech and create the
individual voice streams required by the radio network.
With a TN8271 gateway, the VOX is located in the TN8271.
With a G.711 connector and TN9271 analog gateway, both have a VOX:
■ For a digital telephone network connection, use the VOX that is in the
G.711 connector
■ For an analog network connection, use the VOX that is in the TN9271
The VOX must be carefully configured, otherwise it may be either too

sensitive to noise or take too long to react (which would result in the loss
of the start of the audio).
The recommended setting for the audio threshold is 10 dB above the audio
input line level when no speech is present. If low level line noise breaks
through the VOX, increase this value.
The holdoff (buffer length) is the duration in milliseconds that the input
audio must be continuously above the audio threshold in order to trigger the
VOX. Its purpose is to suppress short transient signals (clicks & pops).
The holdoff value adds to the overall input audio delay. If clicks and pops
break through the VOX, increase this value.
With a telephone network connection, audio from a radio has higher

priority than audio from the PSTN/PABX device. This means that a PTT
from a radio will override any audio from the PSTN/PABX device. This
applies to both group and individual calls.
What the use of voice detection means in practice, when it is enabled:

■ From the radio side, all audio events are considered as voice and are sent
to the telephone gateway. This means that voice is sent, as well as any
radio audio indicators that are enabled, and any loud background noises,
etc. It is important in this case to ensure that only the necessary audio
indicators are present and that all others are turned off.
■ From the telephone side, the VOX decides whether or not to pass
incoming phone audio to the node. The node decides which call
participant gets the floor. If a second telephone party wants to join a
group call (amalgamation), it will only work if VOX is enabled. Use the
Speech Override parameter in the node (Telephony > SIP Lines) to
select the required priority levels for each SIP line.
It is important that VOX operation is tested on your system to ascertain its

suitability for use.
The TN9300 node controller supports:

■ Individual calls to/from a radio unit and a telephone line. Calls can be
established by either party.
■ Group calls from a telephone line to a group on the LMR side. If voice
detection is disabled on all the components in the phone audio path, a
phone user can make a group call that will be heard by all the radios
affiliated to this group, as well as affiliated consoles. But if a radio or
console replies to the call, only the party on the telephone line will hear
the response. The other participants will still stay on the traffic channel
but will only hear audio from the telephone side of the call.
If voice detection is disabled on all the components in the phone audio

path, only one telephone participant in a group call is supported.
Interfacing with If an interface to a SIP enabled PABX is not available, then the telephone
non-SIP phones interconnect requires one or more third-party telephony gateways to
interface the PBX or telephone exchange to the DMR network.
The telephony gateway converts the IP voice traffic from the node to the
signaling format required by the PBX/PSTN and vice versa. SIP is used for
setting up and clearing down calls.
The telephone user dials the number of a SIP line and then overdials the
number of an individual radio or group. The node receives the over-dialed
string and uses the rules in its in-phone table to find a match, replaces the
dialed digits with a number supplied by the in-phone table. It then sets up
the DMR call to the resulting number of the radio or group.
In the reverse direction, the radio user dials a string of numbers. When the
node receives the string, it uses the rules in its out-phone table to find a
match and replace the string with a telephone number. It then sets up the
call to that telephone number, routing it to a suitable FXO group. Out-
phone tables can be used to limit user access to the PSTN, for example
preventing long-distance calls.
eg PABX/PSTN
PBX
interfaces to
telephony equipment
2-wire, 4-wire or E1/T1
Network Gateway(s)
Telephony Gateway
IP switch
Node(s)
Network Address Translation (NAT) is used when traversing firewalls

and represents the node and network gateway on different IP addresses
and ports. This is not supported in Tait DMR networks for SIP connec-
tions, since the protocols used between the node and network gateway
specify IP address destinations. NAT-aware routers that can understand
SIP will not understand Tait internal protocols.
3.2.4 Media/Voice Recording
Tait TN9300 supports media/voice recording in the following ways:
1. The use of Tait’s Voice Recorder Protocol (VRP). Tait developed the
VRP protocol specifically for voice recording. The voice recorder
requires a Tait proprietary VRP interface and the ability to decode
AMBE streams.
Tait has partnered with Eventide to offer media recorders that can be
interfaced to Tait TN9300 DMR networks to provide the ability to
record voice calls and metadata such as the PTT ID and group ID.
These media recorders can be connected to the Tait DMR node for
recording all calls. Recordings are made in a digital format using
native DMR audio.
To configure voice recording on the TN9300, select Settings > Net-
work Parameters and enter the IP addresses of the voice recorders
(up to 2). The port numbers are fixed. Contact Tait for more informa-
tion about the ports.
For more information, refer to Technical Note TN-2623 How to con-
figure the Eventide NexLog Recorder.
RF infrastructure
Video Recorder
Client Node
Digital Voice
Recorder
LAN or WAN
2. If migrating from an analog network, the voice recorder may not

support digital coding and VRP. In this case, one of the following
may apply as a temporary solution.
a. It may be possible to record the voice stream at the console
interface that is performing the transcoding, or receiving of voice
audio (via a TN8271, for example). AIS or DIP support is needed
if connecting the voice recorder to the TN9300 node controller as
a console, or if the voice recorder is connected to your console of
choice (contact your console provider for information on possible
external interfaces).
For configuration information, refer to “AIS Connections” on
page 171 or “DIP Connections” on page 171.
DMR RF infrastructure
AIS/ Analog
DIP line or
line other
TN9300 Optional
Voice
TN8271
Recorder
(required per Dispatcher
call for DIP)
b. Another possibility is to connect your voice recorder via a 4-wire

line through a conventional line interface.
For configuration information, refer to “Conventional Connec-
tions” on page 171.
DMR RF infrastructure
Analog
Conventional line 4-wire
line E&M
TN9300 TN8271
Voice
Recorder
Both of those options should be regarded as temporary, or partial,

solutions when compared to the node’s inbuilt VRP interface in both
metadata, call type and quantity of calls being recorded. For exam-
ple, individual calls that do not include the external interface will not
be recorded. It will be important to ensure that the user associated
with the external interface is configured to belong to all the group
calls that need to be recorded.
Voice recorders are also available from Exacom and Total Recall.
3.2.5 Location Information
Location information services can be connected through the following

interfaces:
■ LIP (refer to TN-1716 DMR Location Services API for more
information)
■ Tait Monitoring Services API (refer to TD-0050-xx Tait DMR and
TaitNet MPT-IP Monitoring Services API Integration Guide for more
information)
3.2.6 Analog FM Base Stations
Conventional analog FM base stations can interface to the Tait DMR

trunked network through network gateways. This is useful for
interoperability with other organizations still using analog FM. It also
enables a staged transition to a DMR network.
e.g. analog base station
interfaces to analog
equipment
4-wire E&M
TN9271
analog
gateway
IP switch
Base stations
Site Equipment
Node(s) with G.711
connector(s)
Private IP Network
When a DMR radio initiates a group call, the node includes the network
gateway in the call if the group includes analog FM radios The network
gateway passes voice to the analog FM base station over its 4-wire E & M
interface. When an analog FM radio transmits, the analog FM base station
provides audio and signaling to the network gateway. The gateway passes
this to the node, which sets up a group call to the group to which the
network gateway belongs. The mapping between the analog FM channel
and the DMR trunked talkgroup is fixed in the network gateway
configuration.
3.2.7 Inter-network Connections
Other TaitNet MPT, MPT-IP and DMR networks can establish an inter-
network connection to the Tait DMR trunked network through a TN9500
Inter-network Gateway.
Inter-network connection cannot be made if the DMR trunked network

uses transmission trunking.
The TN9500 Inter-network Gateway supports the inter-network

transmission of the following call types:
■ Group calls
■ Individual calls
■ SDM text messages6
■ Status calls
■ Priority calls
The following call types, however, are not supported:

■ All ident calls (ALLI)
■ AVL SDMs
■ Stun/revive
3.2.8 Interface Connectivity Options
There are various options that enable connectivity to the following:

■ Tait TeamPTT networks
■ AMBE/AIS-capable console systems
■ G.711/AIS-capable console systems
■ SIP-capable phone systems
■ Legacy analog consoles (via a TN9271 analog gateway or TN8271
network gateway)
■ Non-SIP legacy phone systems (via a TN9271 analog gateway or
TN8271 network and Cisco gateway)
6. Note that there are some SDM size restrictions. Refer to TN9500 Features
in the Migrating TaitNet MPT Networks using the TN9500 System Man-
ual (MNB-00009-xx).
■ Legacy analog base stations (via a TN9271 analog gateway or TN8271
network gateway)
Note that, in the solutions using TN9271 analog gateways or TN8271

network gateways, one network gateway per talk-path is required.
The TN8271 G.711 codec supports both μ-law and a-law. TN9271 ana-
log gateways currently support μ-law.
Tait TeamPTT TeamPTT connectivity consists of TeamPTT connections (same as AIS

connections) from the DMR node to the Tait TeamPTT network.
TM93xx Tait TeamPTT

network
Base station at site
VDP (AMBE) BSP

Node AIS
TN9300
DMR networks connected to Tait TeamPTT must operate in message

trunking mode, transmission trunking is not recommended.
One TeamPTT connection is required for group calls, and additional

TeamPTT connections are required to each smartphone that is able to be
reached or to use individual calls.
AMBE/AIS-capable This connectivity type consists of an AIS connection from the node. It uses
console systems SIP-based and DMRA recognized protocols. This is a scalable solution
(where SIP trunking is supported), and the consoles support the AIS
protocol and AMBE codec.
TM93xx
Third party equipment
Site
TB9300 Dispatch
AIS console console
system
SIP/RTP or
proprietary
VDP (AMBE) BSP RTP (AMBE) AIS
Node
TN9300
Tait equipment
G.711/AIS-capable This connectivity type consists of an AIS connection from the node. It uses
console systems SIP-based and DMRA recognized protocols. This is a scalable solution
(where SIP trunking is supported), and the consoles support the AIS
protocol and G.711 codec. The G.711 connector is used for transcoding.
TM93xx
VDP (AMBE) BSP

G.711
connector
AMBE G.711
Node AIS Dispatch

TN9300 console console
system
AIS
SIP/RTP or
proprietary
Tait equipment
SIP-capable phone This connectivity type appears to be a SIP line (but it uses the G.711
systems connector for transcoding).
TM93xx
VDP (AMBE) BSP

G.711
connector
AMBE G.711
Node PABX/ Phone

TN9300 PSTN AND (analog)
(digital)
SIP (trunk)
FXS
OR
Tait equipment
Phone
(VOIP)
Legacy analog This connectivity type uses a Conventional connection (but it uses the
consoles G.711 connector and TN8271 analog gateway for transcoding, and analog
inputs and outputs).
TM93xx
VDP (AMBE) BSP

G.711
connector
AMBE
Node Third party equipment

TN9300
G.711
Dispatch
Analog console console
4-wire audio* system
E&M Proprietary
TN9271 analog gateway *1 per talk path
Tait equipment
Non-SIP legacy This connectivity type uses a SIP line (but it uses the G.711 connector for
phone systems transcoding).
TM93xx
VDP (AMBE) BSP

G.711
connector Third party equipment
AMBE G.711
Node
TN9300 Telephony gateway
Cisco 2911 w/FXO
SIP
4-wire E&M
Tait equipment audio
FXS
PBX
PABX/PSTN
(analog) Phone
Legacy base This connection type uses a Conventional connection (but it uses the G.711
stations connector and TN8271 analog gateway for transcoding and analog inputs
and outputs).
TM93xx
VDP (AMBE) BSP

G.711 Terminals
connector
AMBE
Node
TN9300
G.711
Analog equipment
(e.g. base station)
4-wire audio*
E&M
TN9271 analog gateway *1 per talk path
Tait equipment Third party equipment
There is also a connectivity option available for DIPv2 dispatch consoles,

that can be connected to the DMR node via IP, and that uses a network
gateway for transcoding the audio streams.
3.2.9 Console Connectivity Protocol Comparisons
MAP27, AIS and DIP are protocols used by some Tait core networks for
console connectivity:
■ AIS (DMR Application Interface Specification) is a specification
created by the DMR association
■ DIP (Dispatcher Interface Protocol) is a Tait protocol documented in the
Dispatcher Interface Protocol Manual (MNA-00014-xx)
■ RAP (Radio Access Protocol) is part of MAP27, an MPT protocol. Tait
MAP27 includes Tait enhancements and modifications to the protocol
as described in the T1411 MAP27 Gateway User’s Manual (MNA-
00017-xx).
The following table provides a feature comparison of these protocols as

used in Tait equipment:
Feature DIP AIS RAP
Registration/Login Supported Supported Supported
Group affiliation Supported Supported Supported
Authentication Not defined Supported Not defined

(with the protocol - not over
the air)
Group call Supported Supported Supported
Individual call Supported Supported Supported
Emergency call Supported Supported Supported
Priority call Supported Supported Supported
All Ident call Not defined Not supported Not defined
Broadcast call Supported Supported Supported
OVCM call Not defined Not supported Not defined
Remote monitoring/ambient Supported Supported Not defined

listening
Encryption Not defined Not supported Not defined
Text message over IP Not defined Not supported Not defined
Short data message Supported Supported Supported
Stun Supported Supported Not defined
Revive Supported Supported Not defined
Kill Not defined Not supported Not defined
Bar Supported Not defined Not defined
Radio Check/Radio Not defined Supported Not defineda

Interrogation over the air
Status Supported Supported Supported
Divert Supported Not defined Supported
Feature DIP AIS RAP
Hold Supported Not defined Not defined
Conference call (join/split) Supported Not defined Not defined
Feature control Supported Not defined Not defined
Packet data calls Supported Not supported Supported
Non prescribed data calls Not available Not available Not defined
Dynamic regroup Supported Supported Partial
AVL/NMEA poll/monitor Supported Not supported Not available
Call monitor Supported Not defined Not defined
Site monitor Not available Not available Not available
TNDS Not supported Not defined Not defined
a. The RAP radio interrogation message is for local interrogation of the

equipment that is connected.
3.2.10 MPT Gateways
The MPT Gateway provides the means to interconnect the DMR network
to external MPT 1327 networks, such as TaitNet MPT, TaitNet MPT-IP or
Nokia ActioNet™.
It operates at the MPT 1327 air interface level. Conceptually the gateway
appears to be a population of radios to the external MPT 1327 network. The
gateway simulates MPT 1327 signaling, so that the external network thinks
it is talking directly to a radio. To the external network it looks like all the
radios in the DMR network are registered on the external system’s site that
the gateway is connected to.
The following components are required for the gateway:

■ T1430 Gateway Site Management (GSM)
■ T1431 Gateway Channel Controller (GCC)
■ Digi TS2 Port Server
The gateway requires a dedicated site on the external network. Each

channel on the external network site requires a Gateway Channel
Controller on the DMR site.
The following diagram shows the gateway interconnections:
TN9300 DMR Site
TB9300 Base TB9300 Base

Ethernet switch
Station Station
Control plus VoIP
TN9300 DMR Node
Ethernet switch Node
Gateway Site
Ethernet switch
Network Network
Serial port server
gateway gateway
Intersite RS232
Intersite
GSM audio
site
bus
GCC GCC
Key
AGI AGI
GSM Gateway Site Module
Actionet Site GCC Gateway Channel Controller
LIC LIC
AGI Actionet Gateway Interface
Control Traffic
Tx/Rx Tx/Rx LIC Line Interface Card
For Actionet systems a TA2529-01 ActioNet Gateway Interface (AGI) is

used to provide electrical level conversion between the Gateway Channel
Controller and the ActioNet Line Interface Card. This hardware interface
will correctly interface the RX/TX signals, as well as provide Tone
Generation and inactivity detection.
For other system types, the Gateway Channel Controller can be connected
to the external channel using normal RF equipment or by directly
connecting the 4-wire audio.
Basic Registration When a radio registers on the DMR network, the gateway will forward this
and Individual Call registration request to the external network. This informs the external
Setup
network that calls to this radio should be routed to the gateway site.
If a radio on the external network places an individual call request to this
radio and the radio is registered at a site on the DMR network then the call
will be routed to the gateway site, and then onto the site where the radio is
registered. If the radio roams back to the external network, the DMR
network receives no notification. If a radio on the external network places
an individual call request to this radio, the individual call request is
processed by the external network as normal. If a radio on the external
network places a call request to a radio on the DMR network, the DMR
node controller will explicitly register the external network radio.
However, in the situation where the individual call request to this radio is
made from a radio on the DMR network the following happens:
1. The network attempts to contact the called radio on the last site at
which it was registered.
2. If Step 1 fails, the network attempts to contact the called radio at any
site in the site zone.
3. The network attempts to contact the called radio at all sites on the
network including the gateway site.
In the situation where a radio has registered on the external network:

■ If contact is made with the radio at the gateway site where previously it
was registered at a site on the DMR network, then the registration
record is updated to reflect its current location. The next call request to
the radio should not require steps 2 and 3 as above.
Speech Call 1. When a group or individual call request is made to a party on the
Requests to the external network, an a RQS message for the call will be sent to the
External Network
external network’s control channel, and the call request will be
queued.
2. If the gateway receives an ACK QUAL0 acknowledgement for the

RQS from the control channel, it ignores it.
3. If the gateway receives a ACKI QUAL1, ACKQ QUAL0 or ACKQ

QUAL1 for the RQS from the control channel, then the call setup
will be queued.
4. If the gateway receives any other type of acknowledgement for the

RQS from the control channel then the call setup is terminated.
5. If the gateway does not receive an acknowledgement from the

control channel within 2 seconds, then the call setup is terminated.
Speech Call 1. If the gateway receives an AHY from an interprefix party it should
Requests from the respond with an ACKX QUAL0.
External Network
2. Otherwise, if the gateway receives a non FOACSU AHY, it responds

with an ACK QUAL0.
3. If the gateway receives a FOACSU AHY, it responds with an ACKI
QUAL0, and sends an $90 outgoing speech call setup request to the
node controller and initializes a new entry in the call table.
4. If the gateway receives a positive acknowledgement from the node

controller for an incoming FOACSU call, it should send an RQQ
STATUS=off-hook to the control channel.
5. If the gateway receives a positive acknowledgement from the node

controller for an incoming FOACSU call, it should send an RQQ
STATUS=off-on to the control channel.
GTC Processing If the gateway receives a GTC from the control channel, it will allocate the
specified traffic channel to the call. If the traffic channel is already
allocated to an existing call and the called/calling parties do not match, then
the existing call will be terminated.
If a call does not already exist on the DMR network then a new call request
will be created. The gateway may be configured to generate hold tones on
the traffic channel to inform the external network that the call is not fully
allocated. If this is a group call, then the call maybe amalgamated into an
existing call.
If a call exists on the DMR network that matches the called and calling
parties in the GTC, and the existing call is queued waiting for the gateway,
the existing call will proceed.
Restricting Groups By default, group calls created on the DMR network are not routed via the
Forwarded via MPT MPT gateway to the external network unless they have been explicitly
Gateway
allowed. To do this, define the groups in the configuration file 7 on each of
the node controllers. Add an agw8.groups line to the file with the
following format:
agw.groups: 7031900 7031901 <group 3> <group 4> etc...
Only group addresses in this list will be forward through to the MPT
gateway. Addresses can be entered in the current numbering scheme
format, as you would enter numbers in the user interface. Groups should be
separated by a space. Enter taitnet reload-cfg or restart the node to
force the node to reload this file.
If this configuration parameter is all, then all group calls on the network
will be routed to the external network. To do this, set the agw.groups
entry to the following:
agw.groups: all
7. Refer to Section 6.23 Node Resource File for node controller configura-
tion file name and directory path.
8. Note that agw refers to the MPT Gateway (historically called the ActioNet
Gateway).
Diversion The network has the following behavior for diversions:
1. Radio on an external network creates diversion.

■ Calls from radios and consoles on the external network to this
radio divert correctly
■ Calls from radios on DMR to this radio will fail. The gateway
will terminate the call setup if the external network responds with
a diversion acknowledgement (ACKT)
■ If the diverted radio roams onto DMR, then calls from radios on
DMR to the diverted radio will setup to the diverted radio rather
than to the diversion destination. If the radio cancels the diversion
on DMR, the diversion will remain in place on the external
network.
2. Radio on DMR creates diversion.

■ Calls from radios on the external network to this radio will fail.
The gateway will terminate the call setup if the node indicates
that the called party is diverted.
■ Calls from radios on DMR to this radio divert correctly
■ If the radio roams onto the external network then calls from
radios on the external network to the diverted radio will setup to
the diverted radio rather than to the diversion destination. If the
radio cancels the diversion on the external network, the diversion
will remain in place on DMR.
Limitations The gateway supports the following features:

■ Normal, high and emergency call request priorities
■ Individual FOACSU and non-FOACSU speech calls
■ Conference and broadcast group speech calls
■ Interprefix calls
The gateway has limited support for:

■ Individual and group status messages (both ways, but external network
to Tait calls use STORE and FORWARD)
■ Individual and group short data messages and MSTs (from external
network only, no STORE or FORWARD)
■ Individual and group short data messages but not MSTs (from Tait to
external network only)
■ PSTN and PABX calls (from external network only)
Messages that are longer than the maximum supported in DMR (see
table) will be rejected.
UDT format (appended data) Maximum SDM size in DMR
Binary 46 bytes
BCD 92 characters
UDT format (appended data) Maximum SDM size in DMR
7-bit coded character (ISO/IEC 646) 52 characters
8-bit coded character (ISO/IEC 8859) 46 characters
Unicode 16-bit UTF-16BE character 23 characters
The gateway does not support the following features:

■ Call priority
■ Include calls
■ Diversion requests across the gateway
■ DMR to external network PSTN and PABX calls
■ Redundancy for the GSM or TS2
4 Fleet Planning
This section provides information to assist in planning the configuration of

the network.
4.1 Managing Fleets

On a DMR network the radios are grouped into fleets. If a network is
owned by an entity that offers network services to customers, then each
customer would have its own fleet of radios. If it is a privately owned
network, a fleet must still be set up for all the radios on the network.
Each fleet can have several options for different sets of call types (local
calls, telephone calls, data calls and so on) and different service areas (the
whole network, just the main city, just the country, and so on). Each fleet is
a named cluster of network numbers. Each radio assigned to the fleet is
programmed with a number from this cluster. Spare numbers are available
for future expansion.
The fleet can optionally have groups. Groups are also network numbers.
Radios that belong to a group join in a call made to that group number.
A radio has only one individual number but it can belong to many groups.
When you add a radio or a group to a fleet, you configure it so that you can
control the access that radio has to the network, or the way that a group call
is set up. Entering the configuration information for a radio or group is
known as validation.
The service area is part of a radio’s validation record. It is that part of the
network’s coverage area a radio is permitted to operate from. The coverage
area is the area where radios can receive signals from the network and the
network can receive signals from the radio. This is determined by the
number and location of sites in your network. The service area is a subset
of the network’s coverage area. Radios must be within their service area to
make or receive calls. This service area relates only to the location of the
radio, it does not limit the area that the radio can make calls to or receive
calls from. Service areas can be set up for individual radios and for groups
of radios.
Tait TN9300 DMR Tier 3 Trunked System Manual Fleet Planning 129
4.2 Profiles and Service Areas
Profiles and service areas let you combine a set of call rights or a set of sites
under a meaningful name and apply them to a radio or group in a single
action.
While the trunked network has many features and configuration options,
the profiles and service areas are used to define the combination of network
features and configuration options that are actually required. For each
service option, you define a profile and/or service area to match.
This makes defining validation information for the radios and groups in a
fleet quicker and less error-prone. Profiles and service areas also make
maintaining validation information easier; you can change one profile or
service area and globally apply the changes to all radios or groups with that
profile or service area.
How does a network provider go about deciding on the service options to

offer? The following gives a hypothetical example.
A network provides coverage for Metropolis city, Newtown, and the

surrounding countryside, see diagram on following page. There is a large
rural area beyond the town. Highway 1 runs through the city and town. The
provider expects business from bus companies, rail networks and other
transport organizations, as well as from utility companies and rural service
industries. Emergency services are also likely to become customers of the
network.
The network has three nodes; Node 1 is in the city, Node 2 is in the town,
and Node 3 is in a small town and serves a large rural area.
The network operator sets up the following profiles and service areas.
However, the network provider also establishes a policy that larger
customers are able to negotiate their own variations, should their needs not
be covered by the standard service options.
130 Fleet Planning Tait TN9300 DMR Tier 3 Trunked System Manual
4.2.1 Service Areas
Bus companies in the city only need city coverage. Those in the town
probably only need town coverage. Transport organizations use the
interstate highway, the town and the city. Emergency services require full
coverage.
The provider set up the following service areas:
Service Area Coverage
Metropolis City Sites 2 - 8
Newtown Site 11
Newtown and rural Sites 10 - 16
Back country Sites 13 - 16
Highway Sites 1 - 2, 4 - 6, and 10 - 12
All Sites 1 - 16
16
13
Country
12
14
15 11
Newtown
10
1
2
4
Metropolis
City
1
9 6 5
8
7
Key
1 Node 1 Site
4.2.2 Profiles
The provider wants to provide a basic set of call types, then to define
several options for additional types. It is decided to include status calls, call
diversion, and intersite individual calls in that basic set. The plan is to
include local group calls in the basic set, because they put little burden on
network resources, but the call rights do not distinguish between individual
and group calls. To make these distinctions, you need to configure the
validation information for each group number. Separate profiles are created
for PSTN calls only and for PSTN/PABX calls. The provider wants
flexibility in the pricing of connections to an organization’s PABX.
Profile Enabled Call Types
Basic Status calls, call diversion, intersite calls, group calls, short data
messages (single-segment transactions)
PSTN As for the Basic call profile, plus PSTN calls
PABX As for the Basic call profile, plus PSTN and PABX calls
When creating user and group profiles, it is important to assign profile

names that clearly identify the type of network equipment for which they
are being created.
For example, when creating unit profiles, you may have need to have
separate profiles for:
■ TeamPTT smartphones
■ Basic mobile radios
■ Non-Tait radios
■ Dispatch consoles
■ Basic portable radios
■ PSTN supervisor portable radios
■ PABX manager portable radios
■ Special squad covert radios
When creating group profiles, you may have need to have separate profiles
for:
■ Dispatch consoles
■ Radios
■ Special groups
The following considerations should be taken into account when creating

profiles:
■ Portable radios may need a profile with shorter call time limits, to help
preserve battery life
■ Dispatch consoles will generally need to be configured for transmit
interrupt and override rights but these features may not be needed for
radios (except perhaps for administrator/managers)
■ Special squad radios may need to be configured to use encryption, and
have the highest voice call access rights
4.3 Choosing a Numbering Scheme

On a DMR trunked network, each radio or group is identified in two ways:
■ Address
The radio address conforms to the DMR standard and is used inter-
nally by the system.
■ Number
The radio number is designed to be easier for humans to work with
and is used for entry and display.
For example:
■ A caller dials the radio number that it wishes to call.
■ The number is translated by the calling radio to an address and sent to
the node as a call request.
■ The called party is notified by the system of a call request from the
calling users address.
■ The called party radio translates the address into a number (which it
may be able to display depending on the radio model).
The number that a radio is assigned depends on the numbering scheme that
is in use. DMR supports the following schemes:
■ MPT 1327
■ MPT 1343
■ ANN
■ DMR standard
■ DMR native
In each scheme every radio has a unique number which is mapped to a

unique DMR address. Radios and groups numbers are grouped into one or
more fleets. The schemes are designed to minimise the number of digits
that have to be dialled, particularly when the calls are between radios that
belong to the same fleet.
The choice of which numbering scheme(s) will be used should be made

before the initial network installation. The numbering scheme is configured
per fleet. In other words, some fleets may be MPT1343, some may be
MPT1327 and some may be DMR, all on the same node.
It is recommended however, that the same numbering scheme be used

for all fleets on a network, as this will enable the ability both to make
inter-fleet calls and the use of a single console.
Fleets with different numbering schemes can often not communicate
with each other (MPT1327 and MPT1343 can, but not with DMR).
Voice recorder connectivity will also be affected in this scenario. This
set up is recommended only for LMR service providers to independent
companies/customers where no communication is required between
customers, and each customer has their own independent console.
4.3.1 MPT 1343 Numbering Scheme
MPT 1343 radio numbers have the format:

■ ppp / ffff / uu (small fleet)
or
■ ppp / ffff / uuu (large fleet)
MPT 1343 group numbers have the format:

■ ppp / FFFF / gg (small fleet)
or
■ ppp / FFFF / ggg (large fleet)
where:
Item Description Permitted range
ppp Number Prefix 200 - 327
ffff Fleet individual number 2001 - 4999

(FIN)
uu Radio unit number 20 - 89 (small fleet)
uuu Radio unit number 200 - 899 (large fleet)
FFFF Fleet group number (FGN) 5000 - 6050
gg Group number 90 - 99 (small fleet)
ggg Group number 900 - 998 (large fleet)
For systems using MPT 1343 numbering, group fleet numbers are always
5000 and above (which when translated to MPT 1327 equates to idents
above 6000).
MPT 1343 dialing on ■ If making a call to member in own fleet:

the radio
only need to dial a two or three-digit number: uu or uuu
■ If making a call to a group in own fleet:
only needs to dial a two or three-digit number: gg or ggg
■ If making an interfleet call:
needs to dial a six or seven digit-number: ffffuu or ffffuuu or FFFFgg
or FFFFggg
■ If making an interprefix call:
needs to dial the full 9 or 10-digit number: pppffffuu or pppffffuuu
or pppFFFFgg or pppFFFFggg
Advantages ■ Easy for the system to determine if a call is to a group or individual radio
■ Can make fleets of any size and fit in to the address map where you like,
making a more compact map that can be easily added to
■ Radios can be programmed to belong to groups outside their own fleet
(i.e. to groups containing radios belonging to more than one fleet)
Disadvantages ■ Impossible for radios to display who the called party is if interfleet or
interprefix calls are made
■ Long dial numbers for interfleet or interprefix calls
■ Easy to program radios incorrectly (e.g. groups)
■ MPT 1343 requires knowledge of the size and base ident of all the fleets
in the prefix
4.3.2 ANN Numbering Scheme
The addresses in each prefix in the ANN numbering scheme are divided up
into a number of fleets with predefined sizes.
Fleet size Fleet size is restricted to one of three options. Within each fleet there is a
range of radio and group addresses. This is outlined below:
Fleet Size Size Radio Group

type (radios) (groups) Number Range Number Range
Large 700 99 200 to 899 900 to 998
Small 70 10 20 to 89 90 to 99
Mini 22 4 20 to 41 90 to 93
The FPP and MEP In each prefix, there are 8100 individual addresses. The first 8000 of these
parameters are divided into ten blocks numbered from 1 to 10. Each block contains 800
addresses and can accommodate one of the following:
■ A single large fleet
■ Ten small fleets
■ Thirty mini fleets
The number of each type of fleet, that can be allocated within a prefix, is
governed by two parameters:
■ Fleet Partitioning Parameter (FPP)
■ Miniaturization Extent Parameter (MEP)
FPP and MEP can have values in the range 0 to 10 and the sum of the two
values must also lie within this range. For each set of values the following
applies:
■ Blocks 1 to FPP are made up of large fleets
■ Blocks (11 - MEP) to 10 are made up of mini sized fleets
■ All other blocks are used for small fleets
■ The number of large fleets = FPP
■ The number of small fleets = (10 - (FPP + MEP)) x 10
■ The number of mini fleets = MEP x 30
Figure 4.1 illustrates how the address space in a prefix is divided up when
FPP = 2 and MEP = 3
Large Small Mini

Block No: 1 2 3 4 5 6 7 8 9 10 Ten blocks of 800
No. of identities each
1 1 10 10 10 10 10 30 30 30
Fleets
Identity: 00002 8002
FPP = 2 MEP = 3
Figure 4.1 ANN numbering when FPP = 2 and MEP = 3
ANN dialled string The following table shows the full ANN dial string required to call a radio:
7pRUUUa R= fleet number UUU=unit number

Large
(0 to 9), (200 to 899=individual,
Fleet
900 to 998 = group)
7prruua rr=fleet number uu=unit number

Small
(00 to 99), (20 to 89 = individual,
Fleet
90 to 99 = group)
Lprruua, b rr=fleet number uu=unit number

Mini
(00 to 99), (20 to 41 = individual,
Fleet
90 to 93 = group),
a. where p = prefix
b. where L = 7,8,9 (which mini fleet)
Prefix The prefix is identical to that used in the MPT 1327 standard (0 to 127).
It is possible to restrict the number of prefixes available in your system by
selecting an appropriate numbering model. The smaller the numbering
model, the fewer digits used by the prefix in an ANN number.
Numbering model Prefixes used Length of prefix
Mini 0 0 digits
Small 0 to 9 1 digits
Large 0 to 99 2 digits
Extra Large 0 to 99 2 digits
100 to 127 3 digits
Fleet number Fleet numbers are made up of two components, The first is referred to as L
and the second as R/rr.
■ L
For large and small fleets L is always 7. For mini fleets L can have the
value 7, 8 or 9.
■ R/rr
For large fleets the fleet number is referred to as R and is a single-digit
in the range 0 to 9.
For small and mini fleets the fleet number is referred to as rr and is a
two-digit number in the range 00 to 99.
When referring to fleets in general, R/rr is often used.
ANN Numbers ANN numbers are made up from L, the prefix, R/rr and the radio or group
number. L is displayed as a single digit. The prefix is displayed with
between 0 and 3 digits according to the numbering model used. For large
fleets R is displayed as a single digit and for small and mini fleets rr is
displayed as two digits. For large fleets the radio or group number is
displayed as 3 digits and for small and mini fleets with 2 digits.
For example the ANN number 7013200 has L = 7, prefix = 01, R = 3 and radio
number = 200.
Assigning L to a To explain how L is assigned we must examine how idents are organized.
fleet Within each block of 800, the idents are arranged between radios and
groups as follows:
A Large Fleet
0 to 699 Radios
700 to 798 Groups
799 Not used
A Small or Mini Fleet
The block is divided up into ten smaller blocks of 80 idents each. Each of
these sub-blocks can hold either one small fleet or three mini fleets. For a
small fleet the sub block is divided as follows.
0 to 69 Radios
70 to 79 Groups
For mini fleets the sub block is divided as follows.
0 to 21 Radios (1st mini fleet)
22 to 43 Radios (2nd mini fleet)
44 to 65 Radios (3rd mini fleet)
66 to 67 Not used
68 to 71 Groups (1st mini fleet)
72 to 75 Groups (2nd mini fleet)
76 to 79 Groups (3rd mini fleet)
All the mini fleets within a sub-block have the same value of rr but different
values of L.
For the first mini fleet in the block, L = 7. For the second, L = 8 and for the
third L = 9.
Assigning R/rr to a For large fleets R can take values in the range 0 to (FPP - 1).
fleet
For small fleets rr can take values in the range (FPP x 10) to (99 - (MEP x
10))
For mini fleets rr can take values in the range (100 - (MEP x 10)) to 99.
The following table shows valid values for R and rr for different values of
FPP and MEP:
FPP 0 1 2 3 4 5 6 7 8 9 10
R N/A 0 0..1 0.2 0..3 0..4 0..5 0..6 0..7 0..8 0..9
MEP
rr small 00..99 10..99 20..99 30..99 40..99 50..99 60..99 70..99 80..99 90..99 N/A
0
rr mini N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
rr small 00..89 10..89 20..89 30..89 40..89 50..89 60..89 70..89 80..89 N/A N/A
1
rr mini 90..99 90..99 90..99 90..99 90..99 90..99 90..99 90..99 90..99 90..99 N/A
rr small 00..79 10..79 20..79 30..79 40..79 50..79 60..79 70..79 N/A N/A N/A
2
rr mini 80..99 80..99 80..99 80..99 80..99 80..99 80..99 80..99 80..99 N/A N/A
rr small 00..69 10..69 20..69 30..69 40..69 50..69 60..69 N/A N/A N/A N/A
3
rr mini 70..99 70..99 70..99 70..99 70..99 70..99 70..99 70..99 N/A N/A N/A
rr small 00..59 10..59 20..59 30..59 40..59 50..59 N/A N/A N/A N/A N/A
4
rr mini 60..99 60..99 60..99 60..99 60..99 60..99 60..99 N/A N/A N/A N/A
rr small 00..49 10..49 20..49 30..49 40..49 N/A N/A N/A N/A N/A N/A
5
rr mini 50..99 50..99 50..99 50..99 50..99 50..99 N/A N/A N/A N/A N/A
rr small 00..39 10..39 20..39 30..39 N/A N/A N/A N/A N/A N/A N/A
6
rr mini 40..99 40..99 40..99 40..99 40..99 N/A N/A N/A N/A N/A N/A
rr small 00..29 10..29 20..29 N/A N/A N/A N/A N/A N/A N/A N/A
7
rr mini 30..99 30..99 30..99 30..99 N/A N/A N/A N/A N/A N/A N/A
rr small 00..19 10..19 N/A N/A N/A N/A N/A N/A N/A N/A N/A
8
rr mini 20..99 20..99 20..99 N/A N/A N/A N/A N/A N/A N/A N/A
rr small 00..09 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
9
rr mini 10..99 10..99 N/A N/A N/A N/A N/A N/A N/A N/A N/A
rr small N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
10
rr mini 0..99 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
Cells in the table that are shaded light grey represent combinations of FPP
and MEP which allow no fleets of the specified size.
Cells in the table that are shaded grey represent invalid combinations of
FPP and MEP.
Advantages ■ Interfleet dialing is accomplished by dialing 5 to 8 digits (MPT 1343

requires 6 or 7 digits)
■ Interprefix dialing is accomplished by dialing 5 to 8 digits (MPT 1343
requires 9 or 10)
■ DMR addresses can be converted to ANN numbers using a simple
algorithm that requires only the values of FPP and MEP. MPT 1343
requires knowledge of the size and base ident of all the fleets in the
prefix.
■ Radios can display the caller ID for interfleet and individual interprefix
calls
■ Interfleet dialing can be blocked if desired. The node/site only requires
the FPP/MEP parameters to work out if a call is an interfleet call.
Disadvantages ■ Fleets and groups have a fixed size

■ You only have a certain number of fleets at each size (i.e. if you use up
all your large fleets, you cannot add more)
■ You must decide when you first commission the system what the FPP/
MEP parameters are, i.e. how many fleets of each size you want, as the
system will only support up to 10 MEP/FPP combinations. These are
applied per prefix (or prefix range)
■ You cannot have radios belonging to a group outside of their own fleet
4.3.3 DMR Standard Numbering Scheme
For full interoperability between manufacturers’ DMR networks and radio

units, a common numbering plan is specified to map between the User-
Interface (UI) and the Air Interface (AI).
The DMR standards based fleet numbering and dialing plan is defined in
Annex E of ETSI TS 102 361-4 V1.7.1 (Part 4: DMR trunking protocol)
for DMR Trunked (Tier 3) operation. This dial plan is backward
compatible with MPT 1327, MPT 1343 and ANN numbering schemes.
Individual Identity Short Subscriber Identity (SSI)
The length of an AI address is 24 bits. AI addresses are split into two parts.
The first 9 bits represent the Network Area Identity (NAI), the next 15 bits
represent the Short Subscriber Identity (SSI) or Short Group Identity (SGI)
as illustrated below.
DMR Air Interface User Address
Short Subscriber Identity (SSI)

Network Area Identity (NAI) or Short Group Identity (SGI)
9 bits 15 bits
ppppppppp / iiiiiiiiiiiiiii
The air interface address allocation is displayed in the following table.
Description Alias Bits Range Note
Network Area Identity NAI 9 32 - 511 MS Number Prefix
(511 assigned to a
special gateway)
Short Subscriber Identity SSI 15 1 - 32200 Short Subscriber

Identities
32201 - 32767 Special Short

Subscriber Identities
Short Group Identity SGI 15 1 - 17000 Group identities
32767 All call identity
Relationship between NAI and Air Interface Radio Address
The NAI value in the range 32 to 510 is assigned to DMR MS Number

Prefix (NP). An NP value of 511 is assigned to a special gateway.
The relationship between the MS NP and NAI is:

NP = NAI + 296
The permissible range is 328 to 806 (479 values in total). The DMR MS NP
values between 200 and 327 are reserved.
Individual Number Fleet Individual Identity
DMR individual radio numbers have the following 8 digit format:

NP (3 digits) + FIN (2 digits) + IN (3 digits)
These are assigned as follows.
Item Description Permitted range Total
NP Number prefix 328 - 806 479 prefix
FIN Fleet individual 20 - 89 70 fleets

number
IN Radio unit individual 200 - 899 see table below

number
To allow some flexibility in allocating numbers to different sized

organizations, the following partitions are assigned to the FIN range.
FIN range Total fleets Description IN range Total units per fleet
20 - 41 22 Large Fleet 200 - 899 700(15400 units total)
42 - 89 48 Small Fleet 200 - 549 350(16800 units total)
This is illustrated as follows:
3-digit Individual Number (IN)

FIN 20 to 41: range is 200 – 899
3-digit DMR Number Prefix (NP) FIN 42 to 89: Range is 200 - 549
(between 328 and 806)
ppp / ff / uuu
2-digit Fleet Individual Number (FIN)

(between 20 and 89)
For Interfleet calls, a shortened 5 digit MS is represented as:

FIN (2 digits) + IN (3 digits).
For calls within your own fleet, a shortened 3 digit MS is represented as:
IN (3 digits)
Group Number Group Identity
The length of SGI is 15 bits. SGI = 0 is reserved. The range of values from
1 to 17 000 represents a group identity.
32 767 is an all call identity. All other values are reserved.
Fleet Group Identity
The complete group identity consists of 8 digits represented as:

NP (3 digits) + FIN (2 digits) + GN (3 digits)
These are assigned as follows:
Item Description Permitted range Total
FGN Fleet Group number 20 - 89 70
GN Group number 900 - 999 100

(7000 groups total)
A shortened 5 digit group identity is represented as:

FIN (2 digits) + IN (3 digits).
A shortened 3 digit group identity is represented as:

IN (3 digits)
3 -d ig it G r o u p N u m b e r (G N )
(ra n g e is 9 0 0 to 9 9 9 )
p p p / ff / g g g
4.3.4 DMR Native Numbering Scheme
The DMR native numbering and dialing plan is defined in Annex G of

ETSI TS 102 361-4 V1.10.1 (Part 4: DMR trunking protocol) for DMR
Trunked (Tier 3) operation.
A DMR native address is a 0-padded 8 digit number that may be anywhere

within the addressable range 00 000 001 to 16 776 415.
To distinguish between individual and group addresses, the number is

followed by an i or a g. This means that address ranges can overlap between
individual and groups.
Notice Fleet sizes are limited to 5999 units and 2100 groups as per
MPT1327 numbering.
If there is a mix of MPT and DMR fleets within a network, the MPT
special/system idents are not allowed to be used as normal unit or group
addresses by DMR fleets using native address numbering.
4.4 Numbering Scheme Conversion

On Tait DMR networks, AIS identities correspond to the 24-bit DMR
identity. Tait equipment supports several fleet numbering schemes. These
interpret the DMR identity to allow display and dialing in formats that are
easier for users of the Tait radios and network equipment. These schemes
are derived from the Tait MPT product family.
For console systems, it is acceptable to map the DMR identity to a named

alias via an address book/directory or alias list. If a named alias facility is
not available then one or more of the following fleeting numbering formats
need to be supported. If this facility is available then fleet numbering
support is not required although it is desirable.
4.4.1 MPT 1327
MPT 1327 groups and radios are each assigned a unique 20-bit number,
consisting of a Prefix (the first seven bits), and an Ident (the remaining
thirteen bits). Prefixes range from 0 to 127, and Idents range from 1 to
8191.
Tait uses this numbering system on most networks.
Numbers are displayed or/and dialed as:

PPPIIII
PPIIII
IIII
PP or PPP is the Prefix and has a valid range of 0-127. In the case where a
2 digit prefix is dialed the first P is assumed to be a 0. When no Prefix is
dialed, the default Prefix is used and this is specified as a configuration
parameter to the equipment.
IIII is the Ident and has a valid range of 1-8191. Individual Idents are in the
range 1-5999 and group Idents are in the range 6000-8100. Calls may also
originate from special Idents in the range 8101 – 8191 and the console
system should accept these.
The Prefix and Ident map to the DMR identity in the following way
Bits 20-24 Bits 13-19 Bits 0-12
Unused Prefix Ident
Where subscriber or talkgroup identities are used in the AIS specification,

AIS addresses take the form:
sip:identity@networkname[:port]
Where:
■ sip identifies a URI address scheme that is specific to AIS
■ identity is the numeric decimal value of the MPT 1327
representation as described above
■ networkname is a domain name or IP address
■ :port is optional and specifies the port number to use for the AIS
protocol
4.4.2 MPT 1343
MPT 1343 numbers are in the form of Fleet Prefix/Fleet Number/Unit Ident
(FP/FN/UI) for individual unit numbers, and Fleet Prefix/Fleet Number/
Group Ident (FP/FN/GI) for group numbers, where Fleet Prefix ranges
from 200 to 327, Fleet Number ranges from 2001 to 6050, and for
individual radios, the Unit Ident ranges from 20 to 89 for a small fleet, or
200 to 899 for a large fleet. Group Idents range from 90 to 99 for a small
fleet, or 900 to 998 for a large fleet.
On Tait networks group fleets have Fleet Numbers in the range 5000 to
6050 and individual fleets have Fleet Numbers in the range of 2001 to
4999.
Tait historically used this numbering system on most networks but it has
been superseded by the MPT 1327 numbering system.
Numbers are displayed or/and dialed as:
XX
XXX
FFFFXX
FFFFXXX
PPPFFFFXX
PPPFFFFXXX
PPP is the Fleet Prefix, FFFF is the Fleet Number and XX or XXX is the
Unit or Group Ident. MPT 1343 numbers convert to MPT 1327 numbers
and these in turn convert to DMR identities as defined in “MPT 1327” on
page 143.
An MPT 1343 number may be converted to MPT 1327 and then the DMR
identities using the following algorithm.
For the Fleet Prefix:

MPT 1327 Prefix = Fleet Prefix - 200
For a 2-digit Unit Ident:

MPT 1327 Ident = Unit Ident + (Fleet Number – 2000) * 2 – 20

For a 2-digit Group Ident:


To convert an MPT 1327 number to MPT 1343, the system must be aware
of the fleets in use on the network and test to determine if the MPT 1327
number is within the fleet. For a network with the following fleets:
Unit Unit Group Group

2 or 3 2 or 3
Prefix Fleet Fleet Fleet Fleet
Digit Digit
Number Size Number Size
Fleet 1 201 2001 20 2 5000 7 2
Fleet 2 201 2100 100 3 5100 70 3
The start and end MPT 1327 numbers for each fleet can be calculated.
First MPT Last MPT

MPT 1327 First MPT Last MPT
1327 1327
Prefix 1327 Unit 1327 Unit
Group Group
Fleet 1 1 = 201–200 2 = (2001 – 21 =2 + 20 - 6000 = 6007 = 6000

2000) *2 1 (5000 – +7
2000) *2
Fleet 2 1 = 201 – 200 = (2100 299 = 200 + 6200 = 6270 = 6200

200 – 2000) *2 100 - 1 (5100 – + 70
2000) *2
To convert the MPT 1327 number, find the associated fleet and its
parameters then use the following algorithm:
PPP = Fleet Prefix = MPT 1327 Prefix + 200
For the Fleet Number:

FFFF = Unit or Group Fleet Number
For a 2-digit Unit Fleet:

XX = Unit Ident = (MPT 1327 Ident – First MPT 1327 Unit) + 20

XXX = Unit Ident = (MPT 1327 Ident – First MPT 1327 Unit) + 200

XX = Unit Ident = (MPT 1327 Ident – First MPT 1327 Group) + 90

XXX = Unit Ident = (MPT 1327 Ident – First MPT 1327 Group) +
900
The full MPT 1343 number is:

Fleet Prefix / Unit or Group Fleet Number / Unit or Group Ident
4.4.3 ANN
In order to convert ANN numbers to DMR raw numbers, you need first to
convert them to MPT 1327, and then convert them from MPT 1327 to
DMR raw numbers as explained in Section 4.4.1 MPT 1327.
To convert an ANN address to an MPT 1327 address:

■ If the ANN address is member of a large fleet then the MPT 1327 ident
(ID for a unit or a group) is ID=(R * 800) + UUU – 198
■ If the ANN address is member of a small fleet then the MPT 1327 ident
(ID for a unit or a group) is ID=(rr * 80) + uu – 18
■ If the ANN address is member of a mini fleet then the MPT 1327 ident
(ID for a unit) is ID=(L * 22) + (rr * 80) + unit number – 172
■ If the ANN address is member of a mini fleet then the MPT 1327 ident
(ID for a group) is ID=(L * 4) + (rr * 80) + group number – 48
R is the fleet number for large fleets

rr is the fleet number for small and mini fleets
UUU is the unit or group number for large fleets
uu is the unit or group number for small fleets
L is always 7 for large and small fleets, and 7,8 or 9 for mini fleets
4.4.4 DMR Standard Numbering Scheme
The DMR standards numbering scheme is explained in Annex E of

ETSI TS 102 361-4.
Number conversion is explained in E.3.1.3.3 Algorithm to convert an
Individual Number to an AI Address.
Individual numbers All Number Prefixes have the same fleet structure. The relationship of NP,
FIN, IN and the raw DMR address is as follows:
■ For dialed digits 20 to 41
AI MS address = (NP - 328) × 8 00016 + (FIN - 20) × 700 + (IN - 200)
+ 100 00116
AI MS address = (NP - 328) × 8 00016 + (FIN - 42) × 350 + (IN - 200)
+ 103C2916
OR (if you do not want to use hexadecimal numbers)

AI MS address = (NP - 328) × 32768 + (FIN - 20) × 700 + (IN - 200) +
1048577
AI MS address = (NP - 328) × 32768 + (FIN - 42) × 350 + (IN - 200) +
1063977
Group numbers All Number Prefixes have the same fleet structure. The relationship of NP,
FGN, GN and the raw DMR address is as follows:
■ ID = (NP - 328) × 8 00016 + (FGN - 20) × 100 + (GN - 900) + 100 00116
OR (if you do not want to use hexadecimal numbers)

■ ID = (NP - 328) × 32768 + (FGN - 20) × 100 + (GN - 900) +
1048577DMR
4.5 Developing a Fleet Allocation Policy
Once you have decided on the numbering scheme(s) to use for each fleet,
you will need to develop a policy for allocating fleets, units and groups.
This process is important as it will be very difficult to change once your
system is up and running. For example, you should consider:
■ How many fleets are you likely to need in the long term?
■ What size fleets will be required?
■ Will your network be set up for partitions? If so, will the partition
classes be based on prefix? If the answer to both these questions is yes,
you will need to assign a group of prefixes to those users who will gain
preferential access.
■ Does the coverage area divide up into self-contained areas? If so, you
may want to divide up prefixes and assign them to regional areas.
■ Do you wish to restrict interfleet calls?
■ Do you wish to allocate unit numbers that relate to work related
numbers. For example a transport company may wish to use radio
numbers that reflect bus route numbers.
5 Configuration
The following network modules need to be configured for DMR network

operation:
■ TN9300 Node Controllers
■ TaitNet Administration Application (version 3 and version 4 users)
■ TB9300, TB7300 and TB9400 Base Stations
■ TN8271 Network Gateways
■ TN9271 Analog Gateways
■ G.711 Connectors
For information on configuration of the administration application, base

stations, gateways and connectors, refer to the appropriate documentation.
This section provides a basic outline of the procedure required to configure

the node for the first time. For more in-depth information on the features
and interfaces available, refer to the relevant section of this manual, or to
the online help for information relating to the fields on each screen.
In a multi-node system, the individual information for each node needs to

be configured at each node (Settings > Local Parameters, and for version 3
and version 4 nodes, in the Administration application for SNMP, NTP,
etc.), but the system-wide parameters only need to be configured on the
control node. Once the network is up and running, the control node
propagates the database of system parameters to the switching nodes (see
“Configuring the Switching Node” on page 185 for details of how to do
this), so that they can act as control node should the links to the control
node fail.
5.1 Before You Begin

Before commencing the configuration procedure, ensure that the following
information is available:
■ Network IP addresses
■ Numbering scheme
■ Fleet allocation information
■ Radio and group information
To configure a control node for the first time, follow the order in which
the following sections have been laid out. This is because some features
have to be created before others can be configured. For example unit/
group profiles and service areas need to be set up before you can start
adding your units and groups.
Tait TN9300 DMR Tier 3 Trunked System Manual Configuration 149

5.2 Logging on to the Control Node
1. Using your web browser, enter the following:
https://nnn.nnn.nnn.nnn
(where nnn.nnn.nnn.nnn is the IP address of your control node).
2. A warning message will appear advising that unauthorized users are

not allowed. To continue, click the Continue button:
a. Version 3 users:
■ Select TN9300 DMR Trunked
■ The login screen will appear
■ On version 3.28 nodes and later, log in using taitnet as your
username and tait as your password.
On all other nodes, including version 2.28 nodes, log in using
admin as your username and tait as your password.
b. Version 4 users:
■ The Administration application login screen will appear
■ Log in to the Administration application
■ Select the control node from the Applications menu
The first time after a node has been reset, the node will display a warn-
ing message about the encryption keys. You should accept the warning.
5.3 Installing License Files

A node must have a valid license file installed before it can operate.
License files can only be generated by Tait and each node must have its
own unique license. If the node has been set up by Tait then an appropriate
license file will have been installed on the node.
5.3.1 Checking That the License File is Correct

1. On the DMR restricted trunking web browser, select Settings >
License.
2. The license state will be displayed, and if it is up-to-date, the features

that are enabled will also be displayed.
3. If you are setting up a new node from scratch, a new license file will
be required.
To get a license file, Tait must be supplied with the host ID of the
node controller that the node will be installed on (see below), and a
list of the features required (see “Licensed Features” on page 152).
150 Configuration Tait TN9300 DMR Tier 3 Trunked System Manual

5.3.2 Obtaining the Host ID
To obtain the host ID, the following options are available:

■ Log on to the node. The host ID can be found in Settings > Local
Parameters > Network connection.
■ Log on to the Administration Application. The host ID can be found in
Configuration > General.
■ An alternative method, for Solaris users only, is to use a terminal
application to log on to the node using an ssh connection. The unix
command host ID can then be used to display the host ID.
5.3.3 Obtaining the license.dat File
Once you have provided the host ID and required features to Tait, you will
be provided a license file called license.dat for the node.
If you are getting multiple licenses, you may combine the license files into
one file that can be installed on all the nodes. Because the license file is a
text file, you can easily combine the information, but each line must be the
full text from the original file. Each node will only use the line in the license
information that matches its host ID.
The following example shows the typical text in a license file:

PRODUCT TN9300 VERSION 1.7 EXPIRY permanent IP 28b2djf8
FEATURESET HA=1:SIP=10:EXPRESS=0:VRP=1:CRYPTO=0:OTAP=0
-c-61121-4b-677f6d-38-59-3f7c-2e6c57
5.3.4 Installing the License File

1. To install the license file on the node go to the DMR web browser
and select Settings > License.
2. Click Upload, then click Choose file from the Upload license dialog
box.
3. Browse to select the license to upload, and click Open.
4. Once the license file has uploaded, the node will check if the license
is valid.

5.3.5 Licensed Features
Node The node can be licensed for the following features:
License Code License Type Description
TNAS300 DMR node Indicates that the node is enabled for DMR (one
license required per node)
TNAS302 High availability nodea Indicates that the node is enabled as a high
availability node (this license is required in addition to
the DMR node license), allowing this node to
synchronize its database to other nodes. It does not
stop a switching node from taking over control if the
control node fails.
One license required to be purchased per network, to
be installed on each node controller.
TNAS303 DIP calls Indicates the number of concurrent calls that can be
made using DIP connections
TNAS304 AIS calls Indicates the number of concurrent calls that can be
made using AIS connections.
In HA, this license is required for all potential control
nodes.
Multiple AIS licenses may be required when
connecting consoles or using Tait TeamPTT.
TNAS305 Data calls Indicates the number of concurrent packet data calls
that can be made
TNAS306 Voice recorder protocol Indicates that the use of voice recorders are allowed.
In HA, this license is required for all potential control
nodes.
TNAS307 DES encryptionb Indicates that DES encryption is allowed
TNAS308 OTAP Enables UDP packets to be sent to and from port

60000. Although OTAP does use data calls, this
license allows for only OTAP messaging to be sent
and received by the node controller. This means that
a Data calls license is not required for general IP
messaging.
If IP data is necessary for other applications, then
TNAS305 is required (1 per concurrent data call).
TNAS309 Telco (SIP) calls Indicates the number of concurrent calls that can be
made using SIP lines.
A maximum of 8 licenses is recommended (as tested
on the Cisco 4331).
Also required for Network Operator calls, and for
phone calls that traverse the TN9500 Inter-network
Gateway.
TNAS310 DMR conventional DMR Tier 2 conventional network license
TNAS311 Inter-network connections Indicates the number of inter-network connections

allowed

TNAS312 Simulcast Allows for trunked DMR simulcast and voted groups.
Base stations in simulcast sites also require
TBAS306 and/or TBAS307 when this license is
installed.
TNAS313 AES encryption Indicates if the use of AES encryption (if installed) is
allowed
TNAS315 ARC4 encryptionb Indicates that ARC4 encryption is allowed
TNAS320 DMR Express6 Indicates that the node will only allow a total of 6 sites
and 24 physical channels (48 logical channels). The
channels do not need to be evenly spread across the
sites. High availability is not available in DMR
Express6.
Base stations will require TBAS302 when this license
is installed.
TNAS321 DMR Express20 Indicates that the node will only allow a total of 20
sites and 80 physical channels (160 logical
channels). The channels do not need to be evenly
spread across the sites. High availability is available
in DMR Express20, in which case a second node is
required.
Base stations will require TBAS305 when this license
is installed.
a. Without the HA license you can have multiple nodes in a network, but no automatic or manual database syn-
chronization can be performed.
b. Without the encryption license the node will only stop encryption for external interfaces (DIP, AIS, SIP, etc.).
Encrypted calls between radios will not be affected.

Base Station In a DMR trunked network, each base station must have one of the licenses
marked below with an asterisk (*), depending on network type. The base
stations can be licensed for the following features:
TBAS300* DMR Trunking Full Allows a reciter to accept connections from any DMR
high tier or unlimited/full node/standalone node.
In single site trunking and fallback modes, this license
entitles a standalone node to control a single site of
up to 20 physical channels.
TBAS302* DMR Trunking Express6 Allows a reciter to accept connections from any DMR
Express6 node/standalone node or DMR Access
standalone node.
Base stations in an Express6 network will also work
with TBAS300 or TBAS303 licenses. However it is
recommended that all base stations at a site have the
same license. This is because, in fallback mode,
base stations with lower licensing levels will not work
correctly with base stations with a higher level
license.
TBAS303* DMR Trunking Access Limits a reciter to only accepting connections from a
DMR Access standalone node.
This license entitles a standalone node to control a
single site of up to four physical channels.
This license must be installed on all base stations at
the site.
TBAS305* DMR Trunking Express20 Allows a reciter to accept connections from any DMR
Express20, DMR Express6 node/standalone node or
DMR Access standalone node.
Base stations in an Express20 network will also work
with the TBAS300 license. However it is
recommended that all base stations at a site have the
same license. This is because, in fallback mode,
base stations with lower licensing levels will not work
correctly with base stations with a higher level
license.

TBAS306 DMR Central Voter Allows a reciter to operate as a central voter in a

DMR simulcast channel group.
It is recommended that all the base stations/channels
at two sites have the central voter license installed for
redundancy purposes. All other channels of the
physical sites will need the satellite license.
Please refer to the TN9300 DMR Channel Group
System Manual (MNB-00010-xx).
TBAS307 DMR Satellite Allows a reciter to operate as a satellite in a DMR

simulcast channel group.
Please refer to the TN9300 DMR Channel Group
System Manual (MNB-00010-xx).
G.711 Connector The G.711 connector is licensed for the following features:
License Code License Type
TNAS800 G.711 transcoder license (quantities vary from 1 to 100)
TNAS801 High availability optiona
a. The high availability feature is currently not supported, but will be re-
leased at a later date.
The G.711 connector application can be co-located on a TN9300 node or a

TN9500 server:
■ If co-located on the TN9500, the total number of transcoders allowed
depends on the other functions operating on the platform:
TNAS800 can be a maximum of 100 or
TNAS800 + TNAS704 + 20* TNAS705 <= 100
■ If co-located on the TN9300 the maximum number of transcoders
allowed is 6
5.4 Loading SSL Certificates
5.4.1 Version 3.xx and Version 4.xx
The Administration application is used to load SSL certificates and keys.

Refer to Section 11.1.9 of the Tait Core Network Installation and
Configuration Manual (MNB-00012-12 and later).
5.4.2 Version 2 and Earlier

1. On the DMR web browser, select Settings > Web Server and click
Edit to update the parameter settings that apply to the welcome page
and SSL certificate.

2. Under the SSL Certificate/Key Upload area, click Upload SSL
certificate to load an SSL certificate file and Upload SSL Key to load
an SSL key file.
The SSL key needs to be decrypted before loading as there is no provi-

sion in this application for entering a passphrase for decrypting the key.
3. Once uploaded to the SSL Certificates area, select the certificate

from the Uploaded list and press Install.
4. A prompt will appear to inform that the node needs to be rebooted

for the certificate to take effect.
5. Once the reboot has been completed, the installed certificate will be
active.
6. To revert to the default self-signed certificate provided by Tait, press

Revert. This will also require a node reboot for the change to take
effect.
5.5 Setting Up Users
5.5.1 Version 3.xxx and Version 4.xx
Centralized authentication (if used) is configured in the Administration

application. User credentials are maintained (added or deleted), in the
Administration application, but must then be enabled on the DMR control
node.
Users set up through the Administration application will, by default, have

an access level of Disabled in the control node. They must be enabled in
the control node by a user with Administrator credentials, by updating their
access level (see “Local Users” below for instructions on how to do this).
Centralized This is configured in the administration application. Only the LDAP rules
Authentication can be updated in the DMR node controller.
Local users should not be created in the DMR control node web browser
if centralized authentication is used on your server.
Local Users Users are created in the Administration Application, but their access level
must be changed to enable access rights in the control node.
1. On the DMR web browser, select Settings > Users.
2. Click on a username and click Edit.
3. Select the appropriate access level for the user.
4. Click Save.

In multi-node systems, once the user has been updated in the control
node, the switching nodes’ user access levels will subsequently auto-
matically be synchronized.
5.5.2 Version 2 and Earlier
Centralized Connections to the server can be authenticated by a remote (i.e. centralized)

Authentication service. Two remote authentication protocols are supported: LDAP and
RADIUS.
Refer to Section 5.15 Configuring Centralized Authentication for

configuration information.
Local Users It is recommended that local users should not be created in the DMR
web browser if centralized authentication is used on your server.
1. On the DMR web browser, select Settings > Users.
2. Click Add to create a new user.
3. Enter relevant user information in the Identity area.
4. Select an Access level from the drop down list:

■ Disabled
■ Read only
■ Fleet Administrator
■ Network Administrator
■ Administrator
5. Enter a password for the user, and enter it again to confirm.
6. Click Save to save information for this user.
7. Add more users as required.
It is recommended that the Administrator level username and password

for your system be updated so that the default values of admin and
tait are changed for security purposes.
5.6 Configuring the Local Parameters

1. On the DMR web browser, select Settings > Local Parameters.
2. Enter the required values or enable the required features for the node
you are currently logged on to from the General, Network
Connection, SNMP and NTP parameters. (Note that some
parameters, such as SNMP and NTP, are not required to be
configured here for version 3 and version 4 users.)

3. Click Save when complete.
5.7 Configuring Network Parameters

1. On the DMR web browser, select Settings > Network Parameters.
2. Enter the required values or enable the required features for your
network from the General, Compliance, Features, Timeouts,
Transmit Interrupt, Authentication Checks, Background Checks,
Signaling, Voice recording, DSCP and Control Channel Utilization
Thresholds parameters. Click Save when complete.
Notice The default numbering scheme parameter under General

defines the default numbering scheme that will be suggested when cre-
ating a new fleet. If mixed numbering formats are required, a different
numbering scheme can be selected when creating each fleet. If ANN is
one of the numbering schemes that will be used by a fleet, then select
Settings > ANN Parameters to define your ANN fleet sizes.
5.8 Configuring Telephony

From release 3.40, where a network gateway is required for a telephony
interface, it can be either a TN8271 network gateway or a Q9571 G.711
connector.
1. On the DMR web browser, select Telephony > SIP Groups.
2. Click Add to create a new SIP group.
3. Enter the required information for each SIP group on your network
by entering each SIP group’s information, and clicking Save, before
clicking Add to create a new SIP group.
4. Select Telephony > Inphone Tables.
5. Click Add to create a new inphone table.
6. Enter the required values for your inphone table for the Identity and
Inphone Rules parameters.
7. Click Save to save this inphone table. Add more inphone tables as
required.
8. Select Telephony > Outphone Tables.
9. Click Add to create a new outphone table.
10. Enter the required values for your outphone table for the Identity and
Outphone Rules parameters.

11. Click Save to save this outphone table. Add more outphone tables as
required.
12. Select Telephony > SIP Lines.
13. Click Add to create a new local SIP line.
14. Enter the required values for your local SIP line for the Identity,
Validation, Client, Network Gateways and Groups parameters.
15. Add group addresses and their outgoing destinations for the local
SIP line, if required.
16. Click Save to save this SIP line. Add more local SIP lines as
required.
17. To create a connection to a remote telephone system using the

TN9500 gateway, select Interfaces > Inter-network Connections,
and click Add.
18. Enter a name and optionally a comment for the inter-network

connection.
19. Select whether the inter-network connection is enabled or not.
20. Enter the same username and password as entered in the TN9500
gateway for this inter-network connection.
21. Select a SIP group from the drop-down list of groups that have been
defined, if required.
22. Click Save.
5.9 Configuring Subscribers
5.9.1 Adding Encryption Keys
Encryption is an optional feature that requires a license. Note that the same
encryption ID and keys must also be programmed into the radio units for
encryption to work.
1. On the DMR web browser, select Subscribers > Encryption Keys.
2. Click Add to create a new key.
3. Select the encryption type. (Only some DMR release versions have
AES encryption types installed.)
4. Enter the required values for your encryption keys in the Identity and
Key sections.
5. Click Save to save this key. Add more keys as required.

5.9.2 Adding Unit/Group Profiles and Service Areas
1. On the DMR web browser, select Subscribers > Unit Profiles.
2. Click Add to create a new unit profile.
3. Enter the required values or enable the required features for your unit
profiles from the Identity, Features, Location Polling, Transmit
Interrupt, Access Level, Minimum Access Level, Call Time Limits,
Call Inactivity Timeouts, Call Answer Timeouts, Registration
Timeout, Supplementary Data and Call Types parameters.
4. Click Save to save this unit profile. Add more unit profiles as
required.
5. Select Subscribers > Unit Service Areas.
6. Click Add to create a new unit service area.
7. Enter the required values for your unit service area parameters.
8. Click Save to save this unit service area. Add more unit service areas
as required.
9. Select Subscribers > Group Profiles.
10. Click Add to create a new group profile.
group profiles from the Identity, Minimum Access Level, Call Time
Limits, Call Inactivity Timeouts, Call Answer Timeouts, Emergency
Call, Features and Transmit Interrupt parameters.
For OTAP configurations, ensure that the group profile’s ‘Priority group
override’ feature is enabled.
It is the radio that actually decides that the voice takes precedence over
data, but, to get the group call grants (GTCs) onto active payload chan-
nels for the voice calls, you need to have the group priority override fea-
ture enabled, otherwise the node does not send the GTCs there for the
radio to make the decision.
12. Click Save to save this group profile. Add more group profiles as
required.
13. Select Subscribers > Group Service Areas.
14. Click Add to create a new group service area.
15. Enter the required values for your group service area parameters.
When external networks are connected to your network, the group ser-
vice area can be configured to allow for group calls to sites at both local
and external networks. Use the Service Area table for listing the local
sites, and the Service Network table for listing the external sites.

16. Click Save to save this group service area. Add more group service
areas as required.
5.9.3 Adding Partition Classes

1. On the DMR web browser, select Subscribers > Partition Classes
2. Click Add to create a new partition class.
partition classes from the Identity, Address Range (of the radio
units), Call Types and Access Level parameters.
4. Click Save to save this partition class. Add more partition classes as
required.
5.9.4 Add Fleets, Units and Groups

1. On the DMR web browser, select Subscribers > Fleets, then click
Add.
2. Enter a name and optionally a comment for the fleet.
3. Optionally enter the name of an administration group. If you do enter

an administration group then only users in the same group will be
able to view or edit the fleet and the units/groups that belong to it.
4. Select the numbering scheme.
5. Enter a prefix number. The fleet will be part of this prefix.
6. If the fleet uses MPT1343 numbering, follow these steps.

a. Enter the number of units and the number of groups for allocation
to the fleet.
b. Click Find Space. The node calculates values for the FIN and
FGN fields
c. If desired, you can edit the calculated values (these will be
checked when you click Save).
7. If the fleet uses DMR standard numbering, follow these steps.

to the fleet.
b. Click Find Space. The node calculates values for the FIN and
FGN fields
8. If the fleet uses DMR native numbering, follow these steps.

to the fleet.

b. Click Find Space. The node calculates values for the Base unit
and Base group fields.
c. If required, you can manually edit the calculated values (these
will be checked when you click Save).
9. If the fleet uses ANN numbering, follow these steps.

a. Select the fleet size (Large, Small, or Mini).
b. Click Find Space. The node calculates values for the L and R (rr)
fields. (The node displays an error message if the ANN number-
ing model does not allow the fleet size you selected or if there is
not enough room in the prefix.)
When adding a fleet with ANN numbering to the network, the FPP and
MEP for the fleet prefix must first be defined under Settings > ANN
Fleet Parameters.
10. If the fleet uses MPT 1327 numbering, follow these steps:
a. Enter the prefix.
b. Enter the number of units and the number of groups for allocation
to the fleet.
c. Click Find Space. The node calculates values for the Base unit
and Base group fields.
d. If required, you can manually edit the calculated values (these
will be checked when you click Save).
11. Optionally enter the first IP address to be assigned to the first

reserved address in the fleet range. This is only recommended for
LIP operation. If left blank, the radio’s register their own IP
addresses.
12. Click Save.
13. Select Subscribers > Fleets > Units.
14. Click Add to enter one or more radio units.
15. In the Identity area, enter the radio number. This must be a number
that lies within the number range assigned to the fleet. If you add
multiple radios, they will be numbered starting from this number.
16. Optionally add a comment to give more information about the radio.
17. If you want to add more than one unit, enter the number of units into
the Number of units to add box.
radio unit(s) from the Validation, Diversion and Group Assignment
parameters.

19. Click Save. Add more radio units as required.
20. Select Subscribers > Fleets > Groups.
21. Click Add to enter one or more groups.
22. In the Identity area, enter the group number. This must be a number
that lies within the number range assigned to the fleet. If you add
multiple groups, they will be numbered starting from this number.
23. Optionally add a comment to give more information about the group.
24. If you want to add more than one group, enter the number of groups
into the Number of groups to add box.
group from the Validation and Diversion parameters.
26. Click Save. Add more groups as required.
5.10 Configuring Nodes and Functional Sites

1. On the DMR web browser, select Network > Nodes.
2. Click Add to create a new node.
3. Enter the required information for each node on your network by

entering each node’s information, and clicking Save, before creating
more new nodes.
4. Select Network > Sites.
5. Click Add to create a new site.
6. Enter the required values or enable the required features for your site
from the Identity, Location, Features, Queuing, Framelength and
Pooled Sites parameters.
7. Click Save to save the site configuration details.
8. Select the site you have created and press View.
9. Select the Channel tab and click Add.
channel from the Identity and Features parameters.
11. Click Save to save the site channel details.
12. Add more channels as required.
13. Select the Partition tab and click Edit, then Add.
14. Enter the address range and select the required partition class for
your partition.

15. Add more partitions as required.
16. Click Save to save the site partition details.
17. Select the Voting Parameters tab and click Edit.
18. Enter the required values or enable the required features for your site
from the Voting Parameters, Adjacent Sites and Adaptive Vote Now
parameters.
For External: Inter-network adjacent sites the external site alias is

required. Refer to Section 5.16 Configuring External Sites for configu-
ration instructions.
19. Click Save to save voting parameter details.
20. Add more sites as required.
5.11 Configuring Dual Control Channels

On sites with a high number of traffic channels and/or a large quantity of
data communications, a second control channel may be configured for use.
Both control channels share a common pool of traffic channels.
In a site with two control channels, you can configure them with the same
syscode or with complementary syscodes that have different PAR values
(A for one control channel, B for the other).
Options that can be selected for dual control channel operation are:
■ Dual - same syscode with identical PAR field (Partition Class A, B or
AB)
■ Dual - different PAR field (Partition Class A or B)
Using PAR values other than AB allows you to split your radio fleet,
forcing some radios to register on category A control channels, while other
radios register on category B control channels. Note: All radios can register
on AB control channels.
Whether the radio will use only logical channel A on control channels, only
logical channel B, or both (AB), requires the Control Category (PAR value)
to be programmed into the radio unit using the programming application
(Trunked > Network Settings > Network Identity form > DMR tab >
Control Category).
Notice If Dual - different PAR is selected and the network detects

that only one control channel is operational at the site, the PAR value of
the remaining control channel reverts to AB to allow all radios to regis-
ter.

DMR WebUI 1. Select Network > Sites, click on the site name and then click the
Configuration tab.
2. Click Edit and select a value from the drop down menu for Dual
control channels. Options are Single, Dual - same syscode, or Dual
- different PAR.
3. Use the Calculate button to assist setting the site syscode and PAR.
If Dual - different PAR is chosen, use of the Calculate feature is
mandatory as the syscode field is disabled.
4. Click Save, then select the channels tab.
5. Edit the channels to enable the dual control feature by selecting the
check box for the ‘Allow control’ parameter in the Features area.
6. Click Save.
Radio Units Radios must be programmed with the control channel to use. For maximum
benefits, ensure that the radios are distributed evenly between the control
channels.
5.12 Configuring Transmission Trunking

When using the transmission trunking feature, users need to be aware of the
following:
■ Each over on each radio involved will be treated as a separate call
■ Only calls configured as broadcast group call types can be processed in
transmission trunking mode (defined in the group profile)
■ All broadcast group calls on a radio with the transmission trunking
option enabled will be processed in transmission trunking mode
■ Transmission trunking must be enabled in both node group profiles and
radio talkgroups for it to work
■ There may be less fluidity in a transmission trunking conversation on a
busy system, however call priorities are more easily enforced, and there
will be more fairness in the ability to access channel time
■ Proceed to talk tones will only be played to the user that actually has the
resource to make a call
■ No PTT contention is possible, as only one user will be granted the right
to talk and the other users in the broadcast group call will be listeners
■ For transmission trunking to work with some consoles, their behavior
might need particular attention and possibly require special
configuration (AIS-connected consoles that support broadcast calls do
support transmission trunking)
■ Transmission trunking is a voice only feature, and as such, has no
impact on data calls
■ Transmission trunking cannot be used in networks that interface to a
TN9500 Inter-Network gateway

■ Transmission trunking cannot be used in networks that use AIS to
interface to Tait TeamPTT
Before setting up transmission trunking, it is recommended that the

talkgroups that are to use this feature be identified.
Configuring the 1. Enable the Transmission Trunking mode option under each desired
node group profile (Subscribers > Group Profiles > Features >
Transmission trunking for broadcast calls).
2. It is recommended that the Call Answer Timeout parameters for

voice calls be set to 1 second (Subscribers > Group Profiles > Call
Answer Timeouts). This is in case a user presses PTT to make the
call, and releases but doesn’t talk.
3. Enable the Allow adaptive GTCs parameter in both Unit Profiles and
Group Profiles. This is to ensure that the radio units are included in
the group call as soon as possible.
4. Click Save.
Configuring radios 1. Configure the desired talkgroups types as broadcast (under

Workgroup WebUI or Fleet Identity)
2. Click Save.
3. Enable the Transmission Trunking option in Trunked Features >

Radio Calls > Calls Options > DMR > DMR > DMR Call Options.
4. Click Save.
5. Enable the Proceed To Talk Tone option in Trunked Features >

Radio Calls > Calls Options > DMR > DMR > DMR Call Options.
6. Click Save.
5.13 Configuring Transmit Interrupt

These instructions describe how to update the node WebUI, and the radio
units, for the transmit interrupt feature.
The transmit interrupt feature needs the following minimum versions:

■ TN9391 Node Controller v2.16.03 or later is required
■ TP9300 and TM9300 DMR Terminals, version 2.19.02 and
programming application 2.19.01 or later is required
■ DMR base station, version 2.50.00.0003 or later is required
The transmit interrupt feature is configurable only when the DMR spec-
ification parameter in Settings > Network Parameters > Compliance is
set to version 1.8.1 or later.

Configuring 1. On the node controller webUI, select Subscribers > Unit Profiles and
profiles select add or edit to configure a unit profile’s Transmit Interrupt area
as required:
■ Can interrupt - If this feature is enabled the radio can interrupt
calls in progress
■ Can be interrupted - If this feature is enabled the radio can be
interrupted if it is in a call
2. Select Subscribers > Group Profiles and select add or edit to

configure a group profile’s Transmit Interrupt area as required:
■ Interrupted by - Specifies who can interrupt these group calls.
Drop down menu options are:
a. Nobody - Group (audio) calls cannot be interrupted
b. Anyone - Group (audio) calls can be interrupted
c. Fleet members only - Group (audio) calls can be interrupted by
any unit in the same fleet
d. Affiliated group members only- Group (audio) calls can be inter-
rupted by any unit affiliated to this group
e. Consoles only - Group (audio) calls can be interrupted by any
party at AIS or DIP end points
Transmit interrupt is for audio interruption, NOT call override.
■ Allow interrupt if talker is unknown - If enabled, transmit

interruption is allowed when the talker is unknown. This could be
due to fading, or if the node has not yet received the caller’s
identity. If disabled, transmit interrupt will not be allowed.
Configuring sites The traffic channel allocation at a site has an impact on the speed that a
transmit interrupt can be sent on the ‘Embedded Outbound Reverse
Channel’ (RC). If the reverse channel is on:
■ A control channel, the interrupt is sent whenever possible
■ A traffic channel with no audio, the interrupt is sent in the next 60ms
■ A traffic channel with audio, the interrupt is sent in the next 720ms
1. On the node controller webUI, select Network > Sites, click the
name of a site, and then click the Configuration tab.
2. Click Edit to configure the Prefer one channel per BS parameter in

the Features area:
■ If enabled, the controller will allocate the first traffic channel on
the base station for calls when possible, leaving a logical channel
idle per base station for potential transmit interrupt signaling (see
diagram below).

This allows for a higher probability of a fast (<60ms) transmit inter-
rupt time, as the reverse signaling can be sent in the next slot.
Prefer one channel per BS parameter
Control Channel Control Channel
Traffic 1 Traffic 1
Traffic 2 Traffic 2
Traffic 3 Traffic 3
Traffic 4 Traffic 4
Traffic 5 Traffic 5
Traffic 6 Traffic 6
Traffic 7 Traffic 7
Disabled Enabled
Configuring To allow control over the transmit interrupt operation or limit the amount
network parameters of attempted transmit interrupt signaling sent on air, the following
parameters can be configured on the node controller webUI:
1. Select Settings > Network Parameters and configure the parameters

in the Transmit Interrupt area as required:
a. Max interrupt attempt duration - This parameter determines the
length of time that transmit interrupt signals are to be sent to the
base station. A setting of 420ms allows at least 2 RC command
insertions on 2 subsequent F bursts when the alternate slot is
occupied by outbound voice traffic.
b. PTT protect duration - This parameter determines the length of
time that PTT protect signals are sent outbound to the base station
to prevent other units from transmitting other than the interrupt-
ing unit. The default is 25 steps (1.5 seconds).
c. Stop PTTs on priority grp override - If this field is enabled, when
a priority group override is initiated other users at the site (even
if they are not in the group call) will be unable to send PTTs (this
will be at all the sites where the group call has been set up).
d. Stop PTTs on emergency group override - If this field is enabled,
when an emergency group override is initiated other users at the
site (even if they are not in the group call) will be unable to send
PTTs (this will be at all the sites where the group call has been set
up).
e. Stop PTTs on All Ident calls - If this field is enabled, when an All
Ident call is initiated other users at the site (even if they are not in
the group call) will be unable to send PTTs (this will be at all the
sites where the group call has been set up).
Notice For the three Stop PTT parameters above (c to e), if the talker
is not interested in the call, the talker audio will be stopped early.

Enabling these three parameters is not recommended on networks with
multiple fleets and group calls.
RC impact on late A radio joining late into an encrypted call will experience additional late
entry performance entry delays if the adjacent slot to it is bearing an encrypted voice call.
on encrypted call
Encryption parameters and RC commands share the F voice bursts in the

DMR voice superframe. The PI bit identifies these 2 bursts, and the base
station alternates these 2 different bursts for every F voice burst.
This will impact late entry performances as follows:

■ The minimum delay to late entry for the encrypted call will be around
three (3) voice superframes (SF), thus around 1080 ms, instead of two
(2) voice superframes (720 ms)
Configuring radios 1. Select Trunked > Radio Calls > Call Options form > DMR tab and
configure the following as required:
2. Radio unit capabilities:

a. Accept Tx Interrupt -Allows the radio to be remotely interrupted
(de-keyed)
b. Initiate Tx Interrupt - Allows the radio to remotely interrupt other
radios
3. Operational control:
a. PTT Press Initiates Tx Interrupt - Interrupt other radios whenever
the PTT is pressed
b. Tx Interrupt Timer - How long to wait for a response from the
system, after initiating a Tx interrupt request

4. Workgroup specific capabilities:
Regardless of individual radio settings to allow transmit interrupt,

workgroups can be configured to allow or block transmit interrupt:
a. Select Trunked > Network Settings > Workgroup Assignments >
Assignments tab:
b. Accept Tx Interrupt: if enabled the radio will cease transmitting
when a Tx interrupt request is received on the reverse channel
c. Initiate Tx Interrupt: if enabled, the radio user can initiate a Tx
interrupt and cease any current transmissions

5.14 Configuring Interface Connections
From release 3.40, where a network gateway is required for an interface
connection, it can be either a TN8271 network gateway or a Q9571
G.711 connector.
5.14.1 AIS Connections
Use this procedure to configure AIS connections, if required.
1. On the DMR web browser, select Interfaces > AIS Connections and
then click Add.
2. Enter the required AIS connection information in the Identity,

Validations and Features areas. (The AIS Identity must also be
configured as a subscriber unit.)
3. Click Save to save this AIS connection information. Add more as

required.
If a unit ID address is dedicated to an AIS connection, it cannot be used

for a radio, even if the AIS connection is disabled. The node will ignore
any radio trying to register with this unit ID.
5.14.2 Conventional Connections
Use this procedure to configure conventional connections, if required.
1. On the DMR web browser, select Interfaces > Conventional

Connections and click Add.
2. Enter the required Conventional connection information in the

Identity and Network Gateway areas. (The conventional connection
Identity must also be configured as a subscriber unit.)
3. Click Save to save this conventional connection information. Add

more as required.
5.14.3 DIP Connections
Use this procedure to configure interfaces to a dispatcher, if required.
1. On the DMR web browser, select Interfaces > DIP Connections and
click Add.
2. Enter the required DIP connection information in the Identity and

Authorised Groups areas. (The DIP Identity must also be configured
as a subscriber unit.)
3. Click Save to save this DIP connection information. Add more as

required.

5.14.4 Inter-network Connections
Use this procedure to configure inter-network connections, if required.
1. On the DMR web browser, select Interfaces > Inter-network

Connections and then click Add.
2. Enter the required inter-network connection information in the

General, Validation and Client areas.
3. Click Save to save this inter-network connection information. Add

more as required.
Notice The ‘Invite without SDP’ feature in the Client area is only
available on the inter-network connection that is supported by the reli-
able provisional scheme in the invite session (RFC6337#section-3.1.2).
This option can be used to synchronize inter-network calls over the
inter-network gateway connections. If this option is not used, the call
times for an inter-network voice call may differ between the inbound
and outbound networks. This option is supported on version 1.12 or
later of the TN9500 Inter-Network Gateway.
5.14.5 TeamPTT Connections
Use this procedure to configure TeamPTT connections, if required.
The AIS calls license (TNAS304) is required for TeamPTT connec-

tions.
1. On the DMR web browser, select Interfaces > TeamPTT

Connections and then click Add.
2. Enter a name and optionally a comment for the TeamPTT

connection.
3. Select whether the TeamPTT connection is enabled or not.
4. Enter the same username and password as entered in the Tait

TeamPTT gateway for this TeamPTT connection. (The username
must be unique.) To change the port number, see below.
Each DMR ID used for the TeamPTT username also has to be config-
ured as a unit in Subscribers > Fleet > Units.
5. Select the required features for the connection.
6. Click Save.
Changing the port The local port number on the node that is used for the TeamPTT service is
number set, by default, to 5062.

1. To change the port number, update the following line in the node
configuration file:
port.node_sip_teamptt:<port_number>
then restart the node.
2. Once the node has restarted, delete the original TeamPTT connection
and add a new one.
5.14.6 IP Data
Use this procedure to enable the use of IP data, if required.
1. On the DMR web browser, select Interfaces > IP Data and then click
Edit.
2. Enter the required IP data information in the General area.
3. Click Save to save the IP Data information.
5.14.7 MPT Gateway
Use this procedure to configure an interface to an MPT conventional

network via an MPT gateway, if required.
1. On the DMR web browser, select Interfaces > MPT Gateway.
2. Click Edit, then Add to enter the port server information for the
network gateway that is the interface to the MPT gateway.
3. Enter the required network gateway IP address and port number.
4. Click Save to save this network gateway information. Add more as

required.
5.15 Configuring Centralized Authentication

DMR networks can be set up with centralized authentication. The LDAP
and RADIUS network protocols for centralized authentication are both
supported.
5.15.1 Version 3 and Version 4
LDAP/Radius configuration for version 3 and version 4 users has been

moved to the Administration application. Only the LDAP rules can be
updated in the DMR node controller.
5.15.2 Version 2 LDAP
The following information is required to configure a DMR node for LDAP:

■ The IP address and port number (typically 389 for LDAP) of the LDAP
server
■ The search base for the LDAP server defines where the search begins in
the LDAP directory. It prevents scanning the whole directory tree if
only a specific branch is sufficient. This setting can affect the response
time if the directory structure is complex with several entries.
■ Group member attribute: specifies the name of the attributes used by
LDAP groups to identify their members
■ Bind DN: typically a user who is allowed to browse the LDAP directory
and read user attributes
■ Bind password: password required for the account allowed to browse
the LDAP directory
■ LDAP rules: mapping rules between local access levels and remote
LDAP groups. This capability ensures that users belonging to a specific
group are given a specific access level. A minimum of one rule is
required.
Configuration 1. On the DMR web browser, select Settings > Authentication and click
procedure for LDAP Edit.
2. Select LDAP from the Remote field drop down.
3. In the LDAP Server area enter the values for your network (as listed
above).
4. In the LDAP Rules area, click Add and create at least one rule.
The table of rules is used to determine the access level of a user. Each
rule is checked in order until a match is found. At least one LDAP
rule must be defined if LDAP is selected as the authentication proto-
col. The LDAP rules associate local access levels to remote LDAP
groups and/or user attributes.
5. Repeat for the next rule you want to define. You can define up to 10
rules. To add a rule to the bottom of the table click Add. Rules should
be added in order of Access level, with the highest first in the table.
The order is important because each rule is checked in order until a
match is found, so to add a rule in the middle of the table, select the
line above which you want the new rule to appear and click Insert.

At least 1 rule needs to be specified, otherwise no users will be success-
fully authenticated by the LDAP server
The following rule table example is provided as an example:
Search Access
Id Group DN (example)
Filter Level
1 cn=Node_Administrator,ou=groups, Administrator
o=support_services,o=client,
dc=taitradio
2 cn=Node_Network_Administrator, Network
ou=groups,o=support_services, administrator
o=client,dc=taitradio
3 cn=Node_Fleet_Administrator, Fleet
ou=groups,o=support_services, administrator
o=client,dc=taitradio
4 Read only
In this example:
■ Users belonging to Node_Administrator LDAP group will have
Administrator access level
■ Users belonging to Node_Network_Administrator LDAP group
will have Network administrator access level
■ Users belonging to Node_Fleet_Administrator LDAP group will
have Fleet administrator access level
■ All other users under the LDAP search base (specified above)
will get Read only access level (it is recommended that this rule
is always included at the end of the rules table)
Optionally, additional Search Filters can be enabled for each access
level. This will add a test against a user attribute.
For example, if department=LMR_Operation was added to the
Search Filter column in row 4 (above) of the table, then only users
with an attribute department with a value set to LMR_Operation
would have Read only access.
The Group DN and Search Filter fields can be used in combination to

allow very flexible user filtering rules.
6. Once finished, click Save.
If no LDAP user with Administrator access level is defined, then it

is imperative that a local administrator account is created in Set-
tings > Users so that local users and passwords can be added and
updated.
7. The node is now configured to authenticate logins against the LDAP

server.

5.15.3 Version 2 RADIUS
The following information is required to configure a DMR node for

RADIUS:
■ The IP address and port number (typically 1812 for RADIUS) of the
RADIUS server
■ The shared secret password - this is used together with an MD5 hashing
algorithm to encrypt passwords
■ Optionally, the node can give predefined access levels to RADIUS
authenticated users. This optional capability requires a specific
configuration on the RADIUS server with the use of the IETF RADIUS
Class attribute.
If no provision has been made on the server for this attribute, then this
option should be left inactive, so that a default access level will be given
to all users authenticated via RADIUS.
Configuration 1. On the DMR web browser, select Settings > Authentication and click
procedure for Edit.
RADIUS
2. Select RADIUS from the Remote field drop down.
3. In the RADIUS server area, enter the IP address, port number, and
shared secret of the RADIUS server.
4. Access level from class attribute can be enabled, if required:

a. If enabled (checked), the node WebUI access level given to an
authenticated user will depend on the value of the IETF RADIUS
Class attribute associated with a given user account in the
RADIUS server.
If the option is enabled and no Class attribute is present, or the returned

value does not match the expected values below, user access will be
denied.
The expected Class attribute values to be provisioned on the

RADIUS server should match the following:
■ TN_administrator, for Administrator access level
■ TN_network_administrator, for Network administrator access
level
■ TN_fleet_administrator, for Fleet administrator access level
■ TN_read_only, for Read only access level
If no RADIUS user with Administrator access level is defined, then it is

imperative that a local administrator account is created in Settings >
Users so that local users and passwords can be added and updated.
b. If disabled (unchecked), the access level for all RADIUS authen-

ticated users will be set to the default: Network administrator.

Make sure that a local administrator account is created in Settings >
Users so that local users and passwords can be added and updated.
5. Click Save.
6. The node is now configured to authenticate logins against the

RADIUS server.
5.16 Configuring External Sites
5.16.1 Overview
There are three types of adjacent site, of which two are external:
■ Local - the site belongs to the same network
■ External inter-network - the site belongs to another network, and is
updated dynamically as it may have dual control channels or rotating
control channels. Also recommended to be used to mitigate channel
failures at remote network sites.
■ External fixed - the site belongs to another network, and has a fixed
control channel RF number and syscode, or it is a cell extender site
Note that for the adjacent site feature to work, the DMR specification
must be 1.6.1 or higher (Settings > Network Parameters > Compliance).
Setting up external sites will involve configuring them on your DMR

network, the TN9500 gateway, and the other networks connected through
the gateway, be they other DMR networks, or MPT-IP or TaitNet MPT
networks.
MPT-IP TN8291 MPT-IP

Site 1 node controller
DMR
Site 1
MPT
Site 1
DMR T1541 MPT

TN9300 DMR trunked
Site 2 node 0
node controller
MPT
Site 2
Fixed
TN9500 Inter-Network
Gateway
In this diagram, the following configurations are required:

■ MPT-IP node controller:
The MPT-IP Site 1 Adjacent Sites table would have two entries:

■ DMR Site 1 configured as an external inter-network site
■ MPT Site 1 configured as an external inter-network site
■ DMR node controller:
The DMR Site 1 Adjacent Sites table would have three entries:
■ MPT-IP Site 1 configured as an external inter-network site
■ DMR Site 2 configured as a local site
The DMR Site 2 Adjacent Sites table would have three entries:
■ DMR Site 1 configured as a local site
■ MPT Site 2 configured as an external fixed site
■ MPT node 0:
The TN9500 is configured in the NMT as a node with three sites:
■ MPT-IP Site 1
■ DMR Site 1
■ DMR Site 2
MPT Site 1 has four adjacent sites (note that configuring the external
inter-network sites as adjacent sites on the NMT will allow for their
control channel RF channel number and syscode information to be
updated automatically):
■ MPT-IP Site 1 is configured as an adjacent site
■ DMR Site 1 is configured as an adjacent site
■ MPT Site 2 is configured as an adjacent site
MPT Site 2 has two adjacent sites (note that configuring the external
inter-network site as an adjacent site on the NMT will allow for its
control channel RF channel number and syscode information to be
updated automatically):
■ MPT Site 1 is configured as an adjacent site
■ TN9500 gateway
The table in the DMR/MPT-IP tab would have five entries:
■ MPT-IP Site 1 would be configured as a dynamic external site
■ DMR Site 1 would be configured as a dynamic external site
■ DMR Site 2 would be configured as a dynamic external site
■ MPT Site 1 would be configured as a dynamic external site
■ MPT Site 2 would be configured as a fixed external site
The table in the MPT tab would have three entries:
■ MPT-IP Site 1 would be configured as a dynamic external site (or
as fixed if required)

■ DMR Site 1 would be configured as a dynamic external site (or
■ DMR Site 2 would be configured as a dynamic external site (or
5.16.2 External Sites
The external site feature enables radios to move seamlessly from one site
on one network to an adjacent site on another network. The external
adjacent site will belong to an external DMR, MPT-IP or TaitNet MPT
network (connected via a TN9500 gateway). The current network will
broadcast information to the radios about this external site (control channel
RF number and syscode) to enable the radios to vote between the site it is
on and the external inter-network site.
In DMR and MPT-IP networks, it is recommended that, for optimal

performance, a maximum of twenty adjacent sites (this includes internal
sites and external fixed sites as well as external inter-network sites) be
configured per site.
In TaitNet MPT networks (where a TN9500 gateway is configured as a

node and the external inter-network sites are configured as TN9500 sites),
up to thirty inter-network adjacent sites can be configured. Of these thirty
sites, a maximum of twenty adjacencies can be set up on a single site.
Only the sites nearest in geographic location to the current control channel
should be configured as adjacent, in order to maintain acceptable
performance during site re-selection.
5.16.3 Configuration Procedure
Before you begin, you will need to know the site aliases of the DMR/MPT-
IP sites that are to be configured as external sites. On your DMR/MPT-IP
WebUI, select Network > Sites, click the name of a site, then click on the
Configuration tab to find the site alias.
For MPT sites, you will need to know the site name. Note that when entered
on the TN9500, any spaces in the name must be removed.
TN9500 1. Log in to the WebUI of the TN9500 Inter-Network Gateway.
2. To add external sites to DMR/MPT-IP networks, select Network >

External Sites > DMR/MPT-IP tab.
3. Select Add to add an external site. The Add DMR/MPT-IP External

Site page is displayed.

4. Enter the site alias. Note that for an MPT site, for ease of site
identification, enter the site’s actual name, but with any spaces
removed.
5. If MPT is selected as the network type, then two additional fields

will be displayed. Enter the site ID and node ID of the MPT site.
6. Click Save to save this external site.
7. To add external sites to MPT networks, select Network > External

Sites > MPT tab.
8. Select Add to add an external site. The Add MPT External Site page
is displayed.
9. Enter the site ID and alias, and select the type from the drop down
box. Options are Dynamic or Fixed.
Note that the site ID must be the same as the site ID assigned to this
site on the NMT (i.e. the order the sites are added must be the same
as the order the sites are added in the NMT).
10. If the type of external site selected is Fixed, then the primary control
channel RF number and syscode must also be entered, and
optionally, the secondary control channel RF number and syscode,
where required for sites with dual control channels.
11. Click Save to save this external site.
DMR/MPT-IP The inter-network protocol (INP) is used to communicate external inter-

network adjacent site information (using the site alias) from the DMR/
MPT-IP network to the TN9500 gateway, when the dynamic adjacency
feature has been enabled. If the site information (site alias, control channel
RF number, syscode) changes, the TN9500 gateway will receive the
updated control channel parameters.
Adjacent sites can be internal network sites, external inter-network sites, or

external fixed sites. The current site’s control channel will regularly send
Vote Now messages (at the period specified by the Vote now interval
parameter) asking radios to compare its signal strength with that of one of
the specified adjacent sites. At the next period interval, the next site in the
adjacent sites table is voted on. This is repeated in a circular fashion with
all the sites in the table.
For optimum results, a maximum of twenty adjacent sites per site is

recommended.
1. Log in to the WebUI of the current network control node.
2. Select Settings > Network Parameters, and in the Features area,

ensure that Dynamic adjacency is enabled. This will allow for the
exchange of external inter-network adjacent site information
between the node and the TN9500 gateway.

3. Click Save.
4. Select Network > Sites, click the name of a site, and then click the
Voting Parameters tab to display voting configuration settings for the
site.
5. Click Edit to add or update Voting Parameters and Adjacent Sites.
6. DMR only: In the Voting Parameters area, enter a site priority for the
current site. Options from the drop down menu are: No priority,
Highest priority, Priority 2 to Priority 6, and Lowest priority.
Each site has an assigned priority, and the vote now messages con-
tain the priority of both the current site and the site to be voted on.
Radio units can be configured whether to use the priority field or not.
When enabled, radio units will use the site with the highest site pri-
ority so long as the site signal strength is above the radio’s pro-
grammed L0 level.
Using the site priority may result in a radio roaming to a site with a
weaker signal strength than the currently registered site.
7. Enter the vote now interval and adjacent site info interval. These
represent the time between broadcasts of vote now and adjacent site
information messages from this site to the radios at the site.
The adjacent site information broadcasts contain the same information

as the vote now broadcast messages, however radios will not leave the
control channel to perform a hunt upon reception of these. The purpose
of the adjacent site information broadcasts is so that radios can build up
an internal hunt list, and prioritize which channels are more important
should they lose contact with their currently registered site.
8. Click Add to add an adjacent site to the end of the table.
9. To insert an adjacent site in the list, click in a row and then click
Insert. A new row is added above the selected row.
10. In the Type field, select External: Inter-network.
11. Enter the alias of the adjacent site. Note that for MPT sites, this is the
site name with any spaces removed.
12. Enter the Priority of the adjacent site.
13. Click OK.
14. Click Save.
TaitNet MPT The inter-node interface (INI) is used to communicate external inter-
network adjacent site information (using the NMT site ID) from the MPT
network to the TN9500 gateway. If the site information (site ID, control
channel RF number or syscode) changes, the TN9500 gateway will receive
the updated control channel parameters.

The TN9500 gateway is configured on the NMT as a node, and the external
DMR/MPT-IP sites are configured as TN9500 sites.
1. Log in to the NMT.
2. From the main window, select Configuration > Network, to display

the Network Configuration window.
3. To add the TN9500 gateway (as a node) press the Add button to
display the Add Node window.
4. In the Node Number box, enter a number for the TN9500. It must be
a number between 0 and 31. It is recommended that you use the
highest number possible (i.e. 31) to distinguish the TN9500 from
other network nodes.
5. In the Node Name box, enter a suitable name for the TN9500.
6. In the Primary Node IP Address box, enter the IP address of the

TN9500.
7. In the Node Mnemonic box, optionally enter a short version of the

TN9500 name, this will be displayed on various windows (for
example, the DAS Monitor window), instead of the node’s full
name.
8. To enter the sites, click on the cells in the Sites table and enter the
name and mnemonic (if required) for each external site configured
on the TN9500. Note that the site ID must be the same on both the
NMT and the TN9500, i.e. they must be entered in the same order.
9. Click on the Active column for each site, to enable it.
10. Press Apply to save your changes then Close to close the window.
11. The external inter-network sites added in Step 8 can now be

configured as adjacent sites for the MPT network’s sites as required.
12. For each site, select Site > Configuration (where Site is the MPT site)
and select the Adjacent Site tab.
13. In the Vote Now area, enable vote now broadcasts, by checking the
box, and enter the required vote now broadcast interval for the
between vote now messages being transmitted.
14. In the Adjacent Sites table, click in the Site area and select the
adjacent sites as required from the pop-up node/site menu that
appears. For each entry, select Vote as the voting mode.
15. Click Apply to save your changes then Close when finished entering
adjacent sites for the selected site.
16. Select other sites as required until all external inter-network sites
have been added as adjacent sites to the relevant MPT sites.

5.17 Configuring an Alternate Channel
These instructions are for setting up an alternate channel (TCCAS) to use
for polling. Each site can be configured with one alternate channel, which
must be on the same physical channel as a control channel.
The alternate channel feature does not require a license.
1. On the DMR web browser, select Settings > Network Parameters.
2. In the Compliance area, select version 1.9.2 from the DMR

specification drop down. (Alternate polling is only supported in
DMR standard 1.9.2.)
3. In the Features area, the Alternate Poll Delay Threshold can be set to
determine if polls on the alternate channel can be marked as delayed.
■ Late poll data can be viewed in the site and channel statistics
reports. No alarm is raised if alternate polls are delayed by the
threshold set here.
■ Excess delays are recorded in both the poll-stats file (under
stats/polling/poll-stats_xxxxx.csv), and are also displayed in
the Alternate Channel Statistics area on the channel status page
(select Network > Sites and select a site, click the Channels tab
and then click on a channel ID to view channel status).
4. To enable the alternate channel at a site, select Network > Sites and
select a site. Click the Channels tab and then click on the channel ID.
Click Edit.
5. In the Features area, enable Allow alternate. It can only become an

alternate channel if the other logical channel on the physical channel
is a control channel:
■ A site generally needs a payload (traffic) channel available. If
there is only one base station at the site, then enabling the traffic
channel to also be an alternate channel is not recommended.
■ If you do configure a channel to be alternate only (e.g. it can
never be a traffic channel), if there is only one base station at the
site, voice calls cannot be made.
6. To select the polling type for the alternate channel, select

Subscribers > Unit Profiles. Create (or select and edit) a unit profile.
7. In the Location Polling area, select the Alternate poll type from the
drop down. Current options are DMR USBD LIP or Disabled.
■ The other selectable polling type is for the control channel. Valid
options for this are DMR Standard, Tait Format 1, Tait Format 2,
DMR USBD LIP format or Disabled. This allows for flexibility
in the types of control channel polling and alternate channel
polling required.

■ When both control poll and alternate poll types are configured,
the node will use the alternate channel if it can, otherwise it will
revert to control channel polling only.
8. Enter the poll intervals for the poll types selected by entering a
numeric value in the first field and selecting the required interval
from the drop down menu. Interval options are seconds, minutes,
hours or days (note that the maximum interval is 1 day).
■ For control polling there is a limit of 5 seconds, but for alternate
polling, 1second is the minimum. The slowest rate is one day.
The DIP interface can now process polling at a speed faster than 5 sec-
onds. The avl.dip_min_report_interval parameter in the controller
configuration file is used to set the minimum interval between sending
AVL reports out on the DIP interface. This value should be set lower
than the lowest poll interval of the terminal population. If the DIP inter-
face is required to monitor large numbers of USBD polls, then reset the
avl.dip_min_report_interval to 3 seconds.
Alternate polls are not recorded in the call records.
To confirm operation, check the following:
1. Alternate channel statistics (see step 3 above).
2. Individual unit location and update times (on the node web browser,
Subscribers > Fleets > Unit > Location tab).
5.18 Configuring Channel Authorization

For channel authorization to work:
■ The DMR network must be operating version 3.38 and version 4 or later
■ The DMR base stations must be operating version 3.20 or later
■ The Tait radios must be operating version 2.28 or later
■ The DMR Programming Application must be version 2.28 or later
The channel authorization feature is enabled by configuring the radios in

the network. DMR networks can operate with a mix of enabled (polite) or
disabled (impolite) radios.
Radio configuration 1. In the DMR Programming Application, select Trunked > Radio
Calls > Call Options > DMR ‘Channel Authorization’.
2. The channel authorization parameters set whether or not the radio

must obtain permission from the network before transmitting voice
or payload data. If there are contending requests from multiple
radios, then only one radio will be granted permission to transmit
defined by the following fields:

a. Channel Authorization: this check box is used to enable/disable
the feature. The default setting is disabled (i.e. not checked).
b. Wait Time: sets how long the radio waits for a response to a chan-
nel authorization request. Default is 400ms.
c. Retries: sets the number of times the radio will resend a channel
authorization request if a response is not received. Default is 1.
d. Maximum Hold Off Time: the radio will wait for a random time
less than or equal to this value before transmitting another chan-
nel authorization request if it has failed to receive a response.
Default is 360ms.
5.19 Configuring Switching Nodes for the First Time

The following procedures need to be repeated for each switching node in
your network.
5.19.1 Logging on to a Switching Node

1. Using your web browser, enter the following:
https://nnn.nnn.nnn.nnn
(where nnn.nnn.nnn.nnn is the IP address of your switching node).
2. A warning message will appear advising that unauthorized users are

not allowed. To continue, click the Continue button.
a. Version 3 users:
■ Select TN9300 DMR Trunked
■ The login screen will appear
■ On version 3.28 nodes and later, log in using taitnet as your
username and tait as your password.
On all other nodes, including version 2.28 nodes, log in using
admin as your username and tait as your password.
b. Version 4 users:
■ The Administration application login screen will appear
■ Log in to the Administration application
■ Select the control node from the Applications menu
5.19.2 Configuring the Switching Node
Before configuring a switching node, it should have already been added to

the control node’s list of nodes (Control node > Network > Nodes), and the
license file for the switching node should be up-to-date (Switching node >
Settings > License). Refer to “Installing License Files” on page 150 if a
license needs to be installed.

Because the control node contains all the required system configuration
settings, and will propagate this information to its switching nodes, the
only settings that need to be configured on the switching node itself are the
local parameters1:
1. Select Settings > Local Parameters and click Edit to enter the
required values for the switching node you are currently logged on
to.
2. Click Save.
3. Select Network > Nodes to add the control node to the switching
node’s node table.
4. Click Save.
5. Select Settings > Local Parameters, click Edit.
6. Under Mode, select Program, then click Save. This will propagate
the full database from the control node.
7. When the database has been propagated from the control node, the
mode will change to Offline.
8. Change the mode back to Online, then click Save.
9. For verification, log on to the control node and select Network >
Status > Nodes to check that the status for the switching node is
correct (i.e. Switching).
1. This is only true if High Availability is set up on all of the nodes. If it is not
set up, the switching nodes will still take over as control nodes in the event
of a control node failure, but their databases will not automatically be syn-
chronized. In this situation, the required information has to be manually
entered into each node.

6 Operations
6.1 Stopping/Starting Node Controller Software
6.1.1 Version 3 and Version 4 Nodes
Use the Administration application to stop/start node controller software.

Refer to Section 10.10 of the Tait Core Networks Installation and
Configuration Manual (MNB-00012-12 and later).
6.1.2 Version 2 Nodes
Using ssh, log on to the node controller as the taitnet user. To stop the node
controller enter:
taitnet stop
To start the node controller enter:

taitnet start
If the node controller is running or the software is hung, you can restart it
by entering:
taitnet restart
6.2 Powering Down the Node Controller

You may need to power down the node controller, for example if you are
moving it to a new location, or you know of a scheduled power outage.
Firstly you should use the WebUI to set the node to Offline. This will stop
the node processing calls.
There are several ways to power off the server in a controlled manner:
Tait Ubuntu ■ If you have access to the node controller hardware, simply press the
power button
■ If you are shutting the machine down remotely, ssh to the node and enter
the following:
sudo poweroff
TaitCentOS ■ If you have access to the node controller hardware, simply press the
power button
Tait TN9300 DMR Tier 3 Trunked System Manual Operations 187

■ If you are shutting the machine down remotely, ssh to the node and
switch to the root user. Enter the following:
poweroff
Solaris ■ If you have access to the node controller hardware, simply press the soft
power button. The shutdown will take a few moments. The button is on
the left of the front panel for the X4200, X4250, X4270 and X3-2
servers.
■ Use the ILOM web interface to select a “graceful shutdown and power
off”.
■ If you are shutting the machine down remotely, ssh to the node and
switch to the root user. Enter the following:
init 5
To restart the node controller, you will have to physically switch it on.
The node should always be powered down in a controlled fashion.

You should always stop the node controller software first, and you
should never remove the power from the node controller unless it is
powered off.
Failure to follow this advice may lead to corrupt system files which will
prevent the node operating.
6.3 Resetting a Node

Under normal circumstances there should never be a need to reset the node.
However, if it is required, there are two ways to reset a node:
Using the Node 1. On the DMR web browser, select Settings > Local Parameters.
2. Click Reboot. This will not only reset the node, but also reboot the
server. It takes several minutes to do a full reboot.
Using an ssh If you are unable to access the Node, you can perform a manual reset using
connection ssh:
1. ssh into the node.
2. On the command line type taitnet restart and press Enter.
3. This will restart all the node processes on the server. Unlike using the
Node however, it will not perform a full reboot, so does not take as
long.
188 Operations Tait TN9300 DMR Tier 3 Trunked System Manual

6.4 Changing to a Local Time Zone
6.4.1 TaitCentOS/Tait Ubuntu - Administration Application 1.16.01 and

Later
Note that only one local time can be used per network. All nodes in a
network must be set to the same time zone, regardless of whether they
are physically located in different time zones.
To change the time zone, log into the Administration application and set the
desired timezone from the Configuration > General page.
The local time will be displayed in all log files as well as the alarms and
call records pages on the WebUI without a UTC offset.
The one exception is the status bar that is always displayed across the top
of the WebUI. It now has a time-date field in the middle that displays the
current time and UTC offset of the node in full date format as follows (for
example):
Tuesday, 2014 February 11 12:51:57 UTC+00:00 (the
node local time is the same as UTC)
node local time is 13 hours ahead of UTC)
6.4.2 TaitCentOS - Administration Application 1.14.xx and Earlier
For first time installation and configuration the time zone can be set during
the installation of TaitCentOS (see the relevant section of the Tait Core
Networks Installation and Configuration Manual).
To change existing systems to a local time zone you must perform the
following procedure:
1. ssh to the node and execute the following as root:

a. Select the required time zone name from /usr/share/
zoneinfo
b. Edit /etc/sysconfig/clock and set ZONE to the filename of
the desired time zone. If the file is in a sub-folder, include the par-
ent folder (e.g.: ZONE=”US/Central”).
c. Execute the following command:
tzdata-update
(Note that if /etc/localtime is a symbolic link, the above
steps might not work. Delete it first when this happens.)

2. Check the date/time by executing the date command:
date
This should display the correct date and time for the newly set time-
zone (see example in step 5). If not login as root, then:
EITHER
a. Correct the date and time using the date command where
<datetime> is a string of numbers representing the month, day,
hour, minute and second, for example date 10061424.40 sets
the date to October 6, 2:24:40 pm:
date <datetime>
OR
b. If using an NTP server, use the ntpdate command, where
<server> is the IP address of a contactable local NTP server:
ntpdate <server>
This command checks the NTP server time, and sets the local
server time (when run as root).
3. Login to the WebUI and check that the date/time is now being
correctly displayed as per the following example:
Fri Jan 17 01:39:30 GMT 2014 (before changing time zone)
Fri Jan 17 14:50:19 NZDT 2014 (after changing time zone)
call records pages on the WebUI without a UTC offset.
of the WebUI. It now has a time-date field in the middle that displays the
example):
6.4.3 Solaris
For first time installation and configuration, refer to the TN9300 Node
Controller Installation Manual (MNB-00001-02), where the time zone can
be set during the installation of Solaris 10.
To change existing systems to a local time zone you must perform the
following procedure:

1. Upgrade to node version 1.13.14 or later.
2. ssh to the node and execute the following as root:

a. Select the required time zone name from /usr/share/lib/
zoneinfo
b. Change the permissions of /etc/default/init so that it is
writable by root:
chmod 755 /etc/default/init
c. Edit the /etc/default/init file, so that a line starting with
TZ= has the timezone name you require, e.g.:
TZ=NZ
d. Execute the commands (where <name> is the timezone name):
rtc -z <name>
rtc -c
3. Shutdown and restart the machine. The recommended command to

shutdown and restart is:
shutdown -y -i6 -g0
(Note that shutdown -y -i5 -g0 will shutdown the system, but
will not restart it.)
4. Check the date/time by executing the date command:

date
This should display the correct date and time for the newly set time-
zone (see example in step 5). If not login as root, then:
EITHER
a. Correct the date and time using the date command where
<datetime> is a string of numbers representing the month, day,
hour, minute and second, for example date 10061424.40 sets
the date to October 6, 2:24:40 pm:
date <datetime>
OR
b. If using an NTP server, use the rdate command, where
<server> is the IP address of a contactable local NTP server:
rdate <server>
This command checks the NTP server time, and sets the local
server time (when run as root).
5. Login to the WebUI and check that the date/time is now being
correctly displayed as per the following example:
Fri Jan 17 01:39:30 GMT 2014 (before changing time zone)
Fri Jan 17 14:50:19 NZDT 2014 (after changing time zone)
call records pages on the WUI without a UTC offset.

of the WUI. It now has a time-date field in the middle that displays the
example):
6.5 Downloading Call Records

The call record files are stored at the control node and kept for 90 days. The
records are stored in two formats:
■ As comma separated values (.csv files)
■ As text (.txt files)
1. On the DMR web browser, select Files > Call Records.
2. Click on the call records file that you wish to download.
3. The Opening call records dialog box appears.
4. Select an appropriate application to open the file type, for example,

Microsoft Excel for csv files, and Notepad++ or UltraEdit for text
files.
For information on determining the contents of a call record, refer to

“Monitoring Calls” on page 221.
6.6 Downloading Alarms

The alarm log files are stored as gzipped comma separated values files
(.csv) and kept for 90 days.
1. On the DMR web browser, select Files > Alarms to display the list
of alarm files.
2. Click on the file you wish to download.
3. The Opening alarm files dialog box appears.
4. Open the selected gzipped alarm log file with an appropriate

application to extract the file from and open it with, for example,
Microsoft Excel.
For information on determining the reasons for an alarm, refer to

“Investigating Alarms” on page 240.

6.7 Downloading Log Files
The log files are stored as gzipped text files (.log). If you experience
issues with the network, Tait may request that you send them particular logs
to help identify the cause of the issues. There are four types of log:
■ Node
■ Packetswitch
■ Watchdog
■ Upgrade (these are only generated when an upgrade to the node
firmware has been performed)
Because log files can be quite large, they may be split into several files.
Each filename is appended with the timestamp of when the log file was
rolled over when the maximum file size was met. The node keeps the
latest 50 log files of each type, so it is recommended that they be regu-
larly downloaded for diagnostic purposes.
1. On the DMR web browser, select Files > Logs to display the list of
log files.
2. Click on the file you wish to download.
3. The Opening log files dialog box appears.
4. Open the selected gzipped log file with an appropriate application to

extract the file from and open it with, for example, Notepad++ or
UltraEdit.
6.8 Downloading General Statistics

Site statistics files are stored as gzipped comma separated values (.csv
files).
1. On the DMR web browser, select Files > General Statistics, then
click the relevant tab to display the list of files.
2. To download statistics files, select the required files using the check
box at the start of each row, and click Download (which only
displays once one or more files have been selected).
3. When the download is complete you will need to uncompress the

file, as it is gzipped. The extracted file can be opened with a
spreadsheet program (for example, Microsoft Excel).
For a complete list of available statistics files and how to monitor them,
refer to Section 7.4 Monitoring Statistics.

6.9 Manually Downloading Files From a Node
SCP (Secure copy) allows you to remotely copy files. If, for example, you
wanted to copy the log file for the 21st of September from the node, you
would enter the following SCP command on the command line of your PC:
Version 4 Nodes scp taitnet@<node_name>:/var/log/taitnet/tait_dmrnc/dmrnc-

(Tait Ubuntu) node_20110921_021619.log
Version 3 Nodes scp taitnet@<node_name>:dmrnc/logs/dmrnc-

(TaitCentOS) node_20110921_021619.log
Version 2 Nodes scp taitnet@<node_name>:logs/dmrnc-

node_20110921_021619.log
Where <node_name> is the IP address of the node you wish to copy from.
SCP will ask for a password before the copy is completed.
There is no way to provide a password on the command line, which would

be useful for automatically downloading files in a cron job. However, you
can bypass this if you use your passphrase to share public/private keys
between your local and remote sources.
Using your passphrase to share public/private keys between your local

and remote sources produces a hole through your remote server login
security and you should fully understand how it works before using it.
6.10 Creating/Restoring Backups

It is good practice to back up your configuration files on a regular basis.
This is especially important when changes are made, such as adding new
channels or radios, or editing unit or group service areas and profiles.
The node configuration is automatically backed up, but it is also a good

idea to periodically perform a manual backup, particularly when a lot of
changes have been made to the configuration parameters.
6.10.1 Version 3 and Version 4 Node Backups
Log in to the Administration application and select Files > Backups then
the tab for your DMR trunked node to list the backup files stored for that
service. Backup files contain server database and configuration settings.
Backup files are created automatically. From the tabs on this page, you can:
■ Download a backup file
■ Upload a backup file so that you can restore a previous configuration

■ Restore the database and configuration settings from a backup file
■ View more information about the contents of a backup file
You cannot create a DMR node backup from the Administration Appli-
cation. You must log in to the node and create the backup there.
Manual Backup 1. On the DMR web browser, select Files > Backups.
2. Click Backup.
3. When an information message appears, click OK.
4. Give the node time to create the backup and then use a browser
command to reload the page. This updates the display to show the
file that has been created.
Download a Backup 1. On the Administration application browser, select Files > Backups
File and the tab for your DMR trunked node.
2. Click the name of the file you wish to download.
3. Save the file to a suitable location on your PC.
Upload a Backup 1. On the Administration application browser, select Files > Backups
File and the tab for your DMR trunked node.
2. Click Upload and then select the name of the file you wish to upload.
When the Upload button is used, the maximum file size that can be
selected to upload is 700 MB, and 2000 MB for version 4.
Restore a 1. On the Administration application browser, select Files > Backups

Configuration from and the tab for your DMR trunked node.
Backup
2. Click the check box to select the row of the file and then click
Restore and confirm. The default restore files will be restored. See
View Backup File Details and Manage Restore Options below for
more advanced restore options.
View Backup File 1. On the Administration application browser, select Files > Backups
Details and Manage and the tab for your DMR trunked node.
Restore Options
2. Click the check box to select the file and then click View.
3. In the Details area, the following fields are displayed:

a. Comment - the information describing the backup.
b. Product version - the version of software that generated the
backup.

c. Host ID, Hostname and Host OS - refer to the server on which the
backup was generated.
4. In the Manifest area all the files contained in the backup are listed in
either the Restore or Ignore boxes. These are default lists that can be
changed. You can move the files between the boxes to provide
advanced control over the settings to be restored.
5. Click the Restore button, and confirm, to restore the files listed in the
Restore box. The files in the Ignore box will not restore.
Delete Backup Files 1. On the Administration application browser, select Files > Backups
and the tab for your DMR trunked node.
2. Select one or more files, using the check box at the start of each row,
and click Delete.
The server automatically deletes backup files that are older than 30
days.
6.10.2 Version 2 Node Backups
Manual backup 1. On the DMR web browser, select Files > Backups.
2. Click Backup.
Restoring 1. On the DMR web browser, select Settings > Local Parameters.
2. Click Edit.
3. Under Mode, click Offline.
4. Click Save.
5. Select Files > Backups.
6. Select the file you wish to restore and click Restore.
7. Select Settings > Local Parameters.
8. Click Edit.
9. Under Mode, click Online.
10. Click Save.

6.11 Upgrading Firmware
From time to time you will need to upgrade the node controller firmware,
which you can do online by uploading the firmware file. This will provide
the benefits of new features and bug fixes.
On the Administration application browser, select Files > Firmware to list

the firmware versions that are currently stored in the server. Buttons allow
you to delete, install or upload firmware files.
Some server firmware versions may not be compatible with other ver-
sions. Please consult the release notes before installing a new firmware
version.
Firmware upgrades should only be done during planned maintenance

times, as system operation is likely to be disturbed.
6.11.1 Version 4 (Tait Ubuntu) Firmware
The following types of firmware file are available from the Administration
application:
■ Updates to the Administration Application
■ Operating system updates
■ Anti Virus updates (pattern files and engine updates)
■ Tait Services, e.g. the TN9300 DMR Node
Tait services are delivered as container ‘Images’, which are bundles that
contain all the software and libraries necessary for the service to oper-
ate.
Upload a New 1. On the Administration application browser, select Files > Firmware.
Firmware Version
2. Click Upload.
3. Navigate to the folder on your PC where the firmware file is located.
4. Select the file and then click Open.

A progress bar indicates how the upload is progressing.
selected to upload is 2 GB.
Upgrade to a New 1. On the Administration application browser, select Files > Firmware.
Firmware Version
2. Select the correct firmware file from the list of uploaded firmware
files.
3. Click Install.

4. The first step of the install process is to validate the upgrade file. The
install will not take place if problems are detected, otherwise the
install process is begun.
5. If you are upgrading the Administration application, it will restart

automatically.
6. If you are upgrading the Operating System, you may need to reboot
the server afterwards. If a reboot is required, a message will appear
on the Configuration > General page.
7. If you are upgrading a Tait service, the installation merely copies the
new container image into a repository on the server. To start using
the new image you must configure the service to use it. At the end of
the installation you will be prompted to do so with the following
message “Installation complete. To use this software you must
configure the service to use it.” If you click Configure, you will be
taken to the configuration page for the service. Select the new
version from the drop down list, ensure Enabled is selected and click
Save.
Validate a Firmware 1. On the Administration application browser, select Files > Firmware.
Version
files.
3. Click Validate.
4. A message is displayed giving the validation status of the selected

file.
To delete a 1. On the Administration application browser, select Files > Firmware.

Firmware Version
files.
3. Click Delete.
4. A message is displayed asking for confirmation of the deletion of the

selected file(s).
6.11.2 Version 3 (TaitCentOS) Firmware
The following types of firmware file are available from the Administration
application:
■ Application packages (for example DMR, or the TN9500, which
includes the Inter-Network gateway, E1 gateway and transcoder
applications)
■ Lone applications (e.g. the Administration application)

■ Operating system updates (this installation may take longer and the
system may be unavailable for up to 15 minutes)
Upload a New 1. On the Administration application browser, select Files > Firmware.
Firmware Version
2. Click Upload.
3. Navigate to the folder on your PC where the firmware file is located.
4. Select the file and then click Open.

A progress bar indicates how the upload is progressing.
selected to upload is for version 3 is 700 MB.
Upgrade to a New 1. On the Administration application browser, select Files > Firmware.
Firmware Version
files.
3. Click Install.
4. The first step of the install process is to validate the upgrade file. The
install will not take place if problems are detected, otherwise the
install process is begun.
5. The server will automatically restart if the upgrade is successful. If

the upgrade fails, it will report an error message and revert to the
previous software version.
Validate a Firmware 1. On the Administration application browser, select Files > Firmware.
Version
files.
3. Click Validate.
4. A message is displayed giving the validation status of the selected

file.
To delete a 1. On the Administration application browser, select Files > Firmware.

Firmware Version
files.
3. Click Delete.
4. A message is displayed asking for confirmation of the deletion of the

selected file(s).

6.11.3 Version 2 Nodes Firmware
Upload a New 1. On the DMR web browser, select Files > Firmware.
Firmware Version
2. Click Upload.
3. A popup will appear, prompting you to cancel or choose a file. Click

Choose File to display the File Upload browser.
4. Select the file to be uploaded. A progress bar will be displayed

whilst the file is uploaded.
Upgrade the Node 1. On the DMR web browser, select Settings > Local Parameters.
to a New Version
2. Click Edit.
3. Under Mode, click Offline.
4. Click Save.
5. Select Files > Firmware.
files.
7. Click Install.
Before installation of the upgrade file takes place, it is first validated to

ensure that it is compatible.
8. The node controller will automatically restart if the upgrade is

successful. If the upgrade fails, it will report an error message and
revert to the previous software version.
9. Select Settings > Local Parameters.
10. Click Edit.
11. Under Mode, click Online.
12. Click Save.
Reverting to an This procedure can also be used to revert to a previous version of the
Earlier Version firmware. When the node controller firmware is upgraded, the old
firmware is not overwritten. Simply select the firmware version you wish
to re-install.

6.12 Setting Up Short Form and Network Operator
Numbers
Outphone tables can be used to enter short form and network operator
numbers for frequently dialed numbers so that radio users can access them
quickly without having to enter a long number. Short form numbers are for
telephone numbers only, whilst network operator numbers can be to a
telephone, dispatcher or radio.
1. Using your web browser, log on to the control node.
2. Select Telephony > Outphone tables.
3. Select or create the outphone table to which you wish to Add the
short form or network operator numbers.
4. In the Length column, enter 4 for a short form number or 5 for a

network operator number1.
5. In the Match column, enter the required short form or network

operator number.
6. In the Replace column, enter the telephone number required.
7. Select the SIP Group required. Do not select the Divert option as the
diversion of short form numbers is not supported.
8. Click Save.
9. Select Subscribers > Fleets > Units to apply the Outphone table to
the Validation rights of the radio units you wish to use short form or
network operator dialing.
6.12.1 Short Form PSTN Calls
Short form dialing allows radio users to access telephone numbers without
having to enter the whole number. Instead, they dial two asterisks (**)
followed by a two-digit code.
Supported short-form numbers are in the range **01 to **15.
1. For four-digit long PABX numbers:

Length - set to 5 (not 4) because radios always add a ‘3’ to the start of
them
Match - always add ‘3’ as the first digit to match because radios always
add a ‘3’ to the start of them (e.g. to match 7xxx, enter 37 in the Match
column)
Replace - don’t forget to replace the ‘3’ when forwarding a 4 digit PABX
number to another node.

6.12.2 Network Operator Calls
The MPT 1343 standard specifies a set of three-digit numbers that radio
users can dial to access operator services such as fault reporting. Each
number can be mapped to an individual address, a group line dispatcher or
a phone number.
A Telco (SIP) calls license (TNAS309) is required for network operator

calls, even if they are set up as diversions to a group or individual radio
ID and not as calls to an actual phone number, because they use the out-
phone table.
Network operator numbers are formed by dialing two asterisks (**)

followed by a three-digit code. The following network operator numbers
can be dialed on the radios:
■ **100 ■ **131 ■ **161 ■ **191
■ **111 ■ **141 ■ **171
■ **121 ■ **151 ■ **181
In addition, the following numbers can be set up for emergency purposes2:

■ **112 or **999
These numbers are equivalent to the special idents 8170 to 8180.
6.13 Using Status Messages

Radios and dispatchers can exchange pre-defined status messages. A code
is sent over the control channel, whose meaning is known by the
receiver(s). A lookup table maps the code to its meaning (each end point
needs to have the status conversion table accurately maintained to avoid
mis-interpretation). 128 status codes are available. All status messages are
given access level priority 1 by default.
2. The network operator emergency number **000 can also be set up on sys-
tems using the ANN numbering system.

The following table provides information for the status messages that are
available, and those that are pre-defined, and therefore cannot be re-used.
DMR
Status Node version
Meaning standards
number support
field valuea
0 Callback request (the values used All node Not

for dispatcher callback request and versions applicable
cancel callback request are
configurable in Tait radios).
1 Available for general use All node Not

to versions applicable
99b
100 Reserved for later use (considered All node Not

to as being for general use until versions applicable
122 otherwise defined)
123 Call terminate 3.36 and newer 1.11.1
124 Cancel an emergency alarm 3.26 and newer 1.9.2
125 Reserved (considered as being for 2.14 and older Not

general use until implemented) applicable
Transmit interrupt 2.16 and newer 1.8.1
126 Reserved (considered as being for All node Not

general use until implemented) versions applicable
Note: in the DMR standards it is for
emergency alarm
127 Status polling service 3.26 and newer 1.9.2
a. The DMR specification TS 102 361-4 DMR Trunking Protocol with which the firm-
ware version is compliant. See WebUI Settings > Network Parameters > Compli-
ance > DMR Specification Version.
b. The default (recommended) configuration in Tait radios is to use 99 for cancel call
back requests.

6.14 Barring Calls
Outphone tables can be used to prevent radios from making specific types
of telephone calls, for example, to numbers beginning with 0900:
1. Using your web browser, log on to the control node.
2. Select Telephony > Outphone tables.
3. Select or create the outphone table to which you wish to add the 0900
number to bar.
4. In the Length column, enter 4.
5. In the Match column, enter 0900.
6. Click Bar from the SIP Group drop down menu.
7. Click Save.
8. Select Subscribers > Fleets > Units to apply the Outphone table to
the Validation rights of the radio units you wish to prevent from
making 0900 calls.
6.15 Setting up Partitions

There are two steps to setting up partitions on the network. First the
partition classes need to be created, then they need to be assigned to the
channels that you wish to reserve.
Partition classes 1. On the DMR web browser, select Subscribers > Partition classes
2. Add the partition classes required, and save.
Channels 1. On the DMR web browser, select Network > Sites
2. Select the required Site. (If adding a new site, you must first enter the
site configuration details and save them. Then add the channels to
the site before creating the partitions).
3. Select the Partition tab and enter the required details.
For more information, refer to Technical Note TN-2662b Information

on how to set up a partition on a DMR System.

6.16 Using Authentication Checking
The Authentication Checks area configures the operation of checks on
radios’ authentication keys. While the node automatically checks any call
requests against its validation database, authentication checking is
available if a higher level of security is needed, for example if it is
suspected that more than one radio is using the same radio number.
An authentication check is carried out as follows. The node polls a radio,

asking it to provide its authentication key. When a response is received, the
node checks it against the key that you entered.
Authentication checking places an additional load on control channels. The

configuration settings need to find a balance between security and network
loading. It is possible to have no automatic authentication checking, but to
poll radios manually as needed.
There are four authentication parameters in Settings > Network

Parameters:
■ Authentication check on registration
■ Authentication check on call
■ Authentication check on transmission interrupt
■ Reject requests that fail authentication
The following sections explain how these parameters work.
6.16.1 On Registration
When this parameter is enabled, an authentication check is carried out

when a radio registers on the network.
1. All registrations will be checked.
2. The site will first acknowledge the registration, but not record it in
the database.
3. The site will send an authentication check to the radio.
4. If it does not get an authentication reply from the radio it will ignore
the registration.
5. If the radio replies, but does not support authentication keys, it will
accept the registration, and record this in the registration database.
6. If the radio replies with an authentication key:

d. If the key matches the database, the registration is accepted, and
recorded in the registration database.
e. If the key does not match the database, the registration will be
ignored.

The node will not send an authentication check if no valid authentica-
tion key is stored in the database.
6.16.2 On Call
When this is enabled, an authentication check is carried out when a radio

makes a call on the network. However, to minimise control channel
loading, the on call authentication check is restricted to once an hour per
radio.
1. On receipt of a call request, an authentication check may be

performed if any one of the following is true:
a. There is no valid authentication key in the database.
b. The last authentication check failed.
c. The last authentication check was good, but was performed over
1 hour ago.
2. The authentication check will be done as part of the call setup, before
the call is sent to channel.
3. If it does not get a reply from the radio, the call will not be set up.
4. If the radio that replies does not support authentication keys, and
there is no key in the database, then it is assumed the radio does not
support authentication keys, and the call setup will continue.
5. If the radio that replies does not support authentication keys but there
is a valid key in the database, it is assumed the radio does support
keys and the call will not be set up. The radio will be asked to re-
register.
6. If the radio replies with an authentication key:

a. If the key matches the database, the call setup will continue.
b. If the key does not match the database, the call request will be
rejected.
6.16.3 On Transmission Interrupt
When this is enabled, an authentication check is carried out when a radio

sends transmit interrupt signals. (This field is not displayed if the DMR
specification is set to 1.6.1 or pre 1.5.1.)
6.16.4 Reject Requests that Fail Authentication
When this is enabled, the system will reject registrations and/or call
requests if the calling party fails an authentication check.

6.17 Replacing a Failed Node
This procedure can be used when at least one of the system’s nodes is still
working and you are replacing a failed node. If all the nodes on the system
have failed, then you must prepare a spare node and restore a recent backup
of the node databases instead of synchronizing it with a live node.
The spare node can be prepared ahead of time with steps 6.17.1 and 6.17.2,
which may take up to two hours.
6.17.1 Install and Configure Solaris 10/TaitCentOS/Tait Ubuntu
Instructions on how to do this are in the Tait Core Networks Installation and
Configuration Manual.
6.17.2 Install the Node Controller Software
Instructions on how to do this are in the Tait Core Networks Installation and
Configuration Manual.
6.17.3 Configure the Node Software

1. Log in to the node and select Settings > Local Parameters.
2. Change the IP address to that of the failed node.
3. Set the node’s priority to that of the failed node.
4. Set the node to offline mode.
5. Apply the changes.
6. The node will reboot. This will take a few minutes. Once this is done,
log back into the node.

6.17.4 Synchronize the New Node with the Control Node
This procedure can only be used on networks with a High Availability

license.
1. On the control node, select Network > Nodes and add the spare node
to this list.
2. Do the same on the spare node; add the other system nodes to
Network > Nodes.
3. Once this is done, on the spare node, put the node into program mode
(Settings > Local Parameters).
At this stage, the spare node will connect to the active control node
and synchronize its database. The spare node’s state will change
from ‘program’ to ‘offline’.
4. Change the mode back to ‘online’ and click Save.
The spare node is now an active node on the system, replacing the failed
node.
6.18 Subscribing to Groups

Subscriptions allow a radio to join or leave a group.
There are three ways to subscribe to groups:
1. Manual group assignment from the node
2. Radio controlled group affiliation
3. Dynamic regrouping from a node or console
Subscription to groups operates as follows:

■ Programmed groups will appear in the Assigned groups list only, and
have to be manually entered (manual group assignment)
■ Radio affiliated groups will appear in the Affiliated groups list only,
which is read only
■ Dynamically regrouped groups will appear in the Dynamic groups list,
which is read-only
The Assigned, Affiliated, and Dynamic groups lists each ‘represent’ a node
database table. With calls to registration-based groups, all three database
tables are searched to construct the list of sites that will be included in the
call.
Tait radios can support:

■ 15 affiliated groups (radio affiliated and dynamic regrouped)

■ 32 programmed groups
The methods for group subscription are described in the following sections.
6.18.1 Manual Group Assignment from the Node
If groups have been entered into the radios at programming time, the only
way that the node can use registration-based groups is if these programmed
assignments are manually entered into the node’s databases using Group
Assignment. This list can also be used to perform dynamic regrouping from
the node (see Section 6.18.3 Dynamic Regrouping).
This is also useful for non-Tait radios which do not support radio controlled
group affiliation.
When other networks are connected through an inter-network connection,

any manual group assignment information from this node is not forwarded
to them. All other connected nodes that have registration based groups for
radios that do not support RCGA should use manual group assignment as
well.
Procedure 1. Select Subscribers > Fleets and then click the name of the fleet that
the unit belongs to.
2. Click the Units tab.
3. Using the arrow buttons at the bottom of the display, or the filter,
navigate to the page displaying the number of the unit.
4. Click the number of the unit and then click Edit to make the page
editable.
5. Edit the Group Assignment section and set the groups you wish the
radio to belong to.
a. To add a group, enter the group address in the Address box and
click Add.
b. To delete a group, select it from the Assigned groups list and click
Delete.
6. Click Save.
This does not affect the radio in any way, as no message is sent to the radio
about which groups the radio is assigned to. All that changes is the list of
sites on which a group call is set up. The node determines which radios are
assigned to the group and then sets up the call on only those sites with at
least one assigned radio.

6.18.2 Radio Affiliation
This feature is supported by Tait radios. To use it, Group Affiliation-related

settings must be enabled in both the node and radio configurations.
Whenever a radio affiliates or de-affiliates from a group it tells the node,

and the node updates the list and the Update received field.
Notice If a radio performs a group affiliation, but one of the groups

in its affiliation list has not yet been set up on the node, a “Not affiliated”
message will be returned, even though all the valid groups have been
accepted by the node.
A Clear Affiliations button is also provided in the node WebUI to clear a

radio’s affiliation information. This only clears the list on the node side and
informs only other connected networks. The radio is not informed and
retains its affiliation details.
Radio affiliation information is forwarded to any other networks connected

through an inter-network connection. All other connected nodes are also
informed via the inter-network connection as to whether the radio units of
a group are registered or not.
6.18.3 Dynamic Regrouping
This feature is supported by Tait radios. To use this feature, Dynamic

regrouping must also be enabled in the radio’s configuration.
Procedure 1. Select Subscribers > Fleets and then click the name of the fleet that
the unit belongs to.
2. Click the Units tab.
3. Using the arrow buttons at the bottom of the display, or the filter,
navigate to the page displaying the number of the unit.
4. Click the number of the unit.
5. If the Assigned groups list does not list all the required groups, click
Edit to move to the Unit Edit page and edit the Group Assignment
section:
a. To add a group, enter the group address in the Address box and
click Add.
b. To delete a group, select it from the Assigned groups list and click
Delete.
6. After you have made the changes required, click Save and you will
be returned to the previous page
7. Select the Remove Dynamic Regroup button to clear all dynamic

regroups from the radio. (This step is not essential, but it will ensure

that the radio’s affiliated groups list and the node’s Affiliated groups
list are synchronized.)
8. Use the <Ctrl> key and the mouse to select up to 15 groups in the
Assigned groups list, then select the Regroup Selected button to send
a dynamic regroup poll to the radio instructing it to affiliate to the
selected groups and to de-affiliate from other dynamic regroup
groups.
Notice Overfilling the radio’s affiliated groups list results in unde-

fined behavior in the radio. To prevent this, an error message is dis-
played if the Regroup Selected button is pressed and the number of
groups in the Affiliated groups list plus the number of selected groups
is greater than 15. An error message is also displayed if the operator has
neglected to select any groups.
To clear dynamic regroups, click the Remove Dynamic Regroup button to

send a dynamic regroup poll to the radio. This causes the radio to de-
affiliate itself from the groups it has in its dynamic affiliation list and be left
only with any RCGA groups.
You can view the status of the poll in the Regroup Status field which will
display one of the following:
State Meaning
- No poll has taken place. The user must poll the radio
for the information
Polling in progress A poll of the radio is in progress
Acknowledged The radio has acknowledged the regroup request
Reply corrupted The radio replied to the poll, but the information
received was unreadable
Not home The radio was not contactable. It may be out of

range or switched off.
Engaged The radio is currently in another call and cannot

reply to the poll
System busy The poll failed because the network is currently

overloaded
Unknown user The radio is not known on the network
Rejected by radio The radio was contacted, but did not send the
requested information. This usually means that the
radio has old firmware.
Unknown failure The poll failed. The reason for the failure is not
known.
Not registered The radio is not registered on the network

The process is illustrated below:
Radio
Unit Node
Regroup Poll
ACK
Group Affiliate
Whenever a dynamic regroup (or clear dynamic regroup) poll is sent, the
radio must first acknowledge it before the node updates its Dynamic Group
list. Furthermore, given that the Group Affiliation related settings are
enabled in the radio’s configuration, the radio will send an affiliation
message with the list of groups it remains affiliated to (but it does not
specify whether each group is radio affiliated or dynamically regrouped).
The node updates the Group Affiliation list groups list with this
information.
Dynamic regrouping information is forwarded to any other networks

connected through an inter-network connection, similar to group
affiliations but with a different message.
The procedure outlined above is for performing dynamic regrouping

through the node WebUI, but dynamic regrouping can also be performed
through an AIS console or a Tait dispatch console.
6.18.4 Radio Configuration

For successful regrouping, the radio units must also be enabled for the
following:
■ Dynamic regrouping must be enabled
■ Include Dynamic Groups in Affiliation should be made selectable
■ RCGA groups should be made selectable
■ Group Affiliation on Regroup must be enabled

6.19 Enabling Encryption
For encryption to work, the same key IDs and key variables need to be set
up in both the nodes and radio units on the network. For node
configuration, see “Adding Encryption Keys” on page 159.
6.19.1 Configuring Tait Radios for Encryption

1. Log on to subscriber programming software.
2. Create the Key on the Key Setup screen:
The key type, key ID and key variable created here must also be
entered on the DMR node WebUI. Each radio can be configured with
up to 4 encryption keys.
3. Then update the Encryption parameters in Network Settings:

6.20 Adding SIP Lines to Outgoing Group Calls
SIP-connected devices have always been able to initiate group calls, but
from release 2.04 they can now also be affiliated to a group so that they are
included in all calls to that group address.
This provides support for low-tier SIP-connected dispatchers, e.g. the ETC
desktop Mic CS-74.
Group calls from SIP line to SIP line are not supported.
Configuring the SIP lines can be added to outgoing group calls by entering up to four group
Node addresses and the associated destination (extension) numbers to each SIP
line.
When making a group call, the node will check if the group address is
configured in SIP lines and, if so, will then try to make a SIP call to the
corresponding SIP lines.
1. On the DMR web browser, select Telephony > SIP Lines.
2. Click Add to create a new SIP line, or to update an existing SIP line,
select the line and click Edit.
3. Enter/edit the required values for your SIP line for the Identity and
Validation parameters.
4. Add group addresses and their outgoing destinations for the SIP line,
if required.
5. Click Save to save this SIP line. Add/edit more SIP lines as required.
Configuring the Configuration settings for the ETC desktop Mic CS-74 are suggested as
ETC CS-74 follows:
■ Jitter buffer: 100ms
■ Master volume level: 80%
■ Mic volume: 40 %
■ NGW audio level setting: default

6.21 Upgrading DMR Express6 or DMR Express20 to
DMR Full
The following sections describe how to upgrade a DMR Express6 licensed
network to a DMR Express20 or DMR Full licensed network. They can
also be used to upgrade from DMR Express20 to DMR Full. For
information on DMR network types see “Network Dimensions” on
page 27.
6.21.1 Before You Begin
Before commencing the upgrade process, it is important to ensure that you

have all the new licenses that are required for your DMR Full network to
operate correctly.
1. Request the required license(s) for the base stations currently

connected to your TN9300 node controller. For each base station, an
upgraded base station license must be activated before proceeding
with the node license upgrade. Otherwise, a license alarm will be
raised for each base station connected to the TN9300 node once the
upgrade is finished.
2. Request a DMR Full license for your TN9300 node controller. In

order to preserve the other features of your system, the license
request should contain the features already activated by your current
license.
3. In the case of DMR Express6 networks, the High Availability

(TNAS302) license is not available. High Availability (HA) is only
supported in either DMR Full or DMR Express20 and will require a
separate license.
Notice If upgrading from DMR Express6 to a multi-node system, we

recommend the upgrade be done first to your original node. Additional
nodes for HA or switching should be added at a later stage, when the
license upgrade is complete. The procedure for adding HA nodes can be
found in Section 2.12 Redundancy and High Availability. For switching
nodes, refer to Section 5.19 Configuring Switching Nodes for the First
Time.
6.21.2 Upgrade Procedure
The upgrade procedure needs to be done in the following order, other-

wise loss of operation may occur.
1. Backup the current license file(s) so that they can be restored in case
the upload procedure for the new license is interrupted or fails.
a. Login to an ssh session (Tait Ubuntu users, see note for Version
4 users in Section 6.22 Additional taitnet commands).

b. Enter the following commands:
cd dmrnc
cp license.dat license.dat.backup
2. Upload the new license(s) on each of the base station(s) registered as

channels on the DMR Express6 or DMR Express20 system by
accessing the base station WebUI: Settings > Licenses tab. Under
‘Enable feature’, upload the feature license key and select ‘Enable’.
3. Upload the node license by accessing the TN9300 node controller

WebUI: Settings > Local Parameters. Click Edit and then scroll
down to the License area. Click the Upload button and select the
license file which you have received from your license request.
The TN9300 network is now licensed to operate as a DMR Full or
DMR Express20 system. There is no need to set the node offline dur-
ing the upgrade. Once the upgrade is complete, your network can be
enlarged to the limits prescribed in Section 2.1 Network Dimen-
sions.
The existing SIP, DIP, AIS and other interfaces should work as usual (as
previously licensed under the DMR Express6 or DMR Express20 sys-
tem). An upgrade only increases the number of sites and channels that
can be added to the system, as well as (for an upgrade from DMR
Express6) adding the ability to install an HA license, if required.
If specific interfaces were not initially enabled on the DMR Express6 or

Express20 system (because of licensing), then the correct licenses must
be requested and added as part of the upgrade.
4. Any further base stations to be added as channels to the system will

also need to have DMR Full or Express20 licenses enabled for these
to be operational.

6.22 Additional taitnet commands
Using an ssh script, you can run the following taitnet commands to
manually control the node. You must be in the appropriate directory
(dmrnc) to enter the commands.
Version 4 users only. Before entering a command, you need to first log
into the container. Enter docker exec -it tait_dmrnc bash, fol-
lowed by cd dmrnc. Then enter your command(s) as required. When
you are ready to logout, enter logout or just press Ctrl-d. This will
return you to the command shell on the host server.
For version 3 and version 4 nodes, all commands must be preceded with
a dot and forward slash (./), for example ./taitnet backup
taitnet backup Perform a backup of the database files.
taitnet build Print the software version and build number of the currently running node
to the screen. The digits after the last . (period) represent the build number.
Example: 1.02.05.03
taitnet clean- Delete all log files and core files (if they exist), then restart the node
restart controller software. Tait does not recommend using this command without
good reason.
taitnet log Print a running copy of the node log to the console. Type <Ctrl>+c to stop.
taitnet net Re-read the network address parameter in the configuration file3 without
restarting the node.
taitnet Re-read the configuration file. This causes all parameters in this file to be
reload-cfg reloaded into the node software without restarting the node. Most, but not
all, parameters specified in the configuration file can be changed using this
command. To execute a change of the network address parameter use the
command taitnet net. Many parameter values are attached to a timer
that executes every minute, so it can take up to one minute from the time
taitnet reload-cfg is run until the change occurs.
taitnet Check if any of the logging levels in the configuration file have changed,
reload-log- and change the logging appropriately, without rebooting the node.
level
taitnet Stop the node if running, and then restart it.

restart
taitnet Perform a restore of the database files.

restore
taitnet start Start the node. Do not use this command if the node is running already.

taitnet start- Start the node linked to the libumem library. This adds a number of
debug-mode debugging features and modifies the way user memory is allocated within
the processor. Tait Technical Support may request that you restart a node
using this command in order to help trace and debug software errors. This
command should not be used unless Tait Technical Support requests its use.
taitnet start- Start the node in program mode. Do not use this command if the node is
program-mode already running, instead use the Web interface to move the node into
program mode.
taitnet status If the node controller software is running (in any mode, including program
mode) then print Node is running to the console screen, otherwise print
Node is NOT running to the console screen.
taitnet stop Stop the node. This will disable the WebUI as well.
taitnet Print the software version number of the currently running node to the
version screen.
Example: 1.02.05
6.23 Node Resource File
6.23.1 Version 3 and Version 4 Nodes Resource File
TaitCentos File The version 3 node has a resource configuration file (tait_dmrnc.cfg),
Location located in the /home/taitnet/dmrnc directory. This file provides some
limited configuration parameters that cannot be changed when logged on
to the node. It is not recommended that they are changed unless Tait
Technical Support has requested it. These parameters are read at startup
and whenever the command ./taitnet reload-cfg is executed. The
file has to be edited by a text editor such as ‘vi’.
Tait Ubuntu File In version 4 nodes, the resource configuration file (tait_dmrnc.cfg), is
Location located inside the container in /home/taitnet/dmrnc. If a parameter has
been edited, you must then go to the directory /home/taitnet/dmrnc and
run the following command ./taitnet reload-cfg.
If changes are made to tait_dmrnc.cfg at one node, the same

changes must be made to the tait_dmrnc.cfg file on all other nodes
in the network
Only the parameter agw.groups should be modified by the customer

without Tait Technical Support recommendation:
agw.groups This is a list of which groups should be sent to the MPT gateway if enabled.
Groups are separated by a space. By default no groups are enabled.

6.23.2 Version 2 Nodes Resource File
The node has a resource configuration file (node.cfg), located in the

taitnet main directory. This file provides some limited configuration
parameters that cannot be changed when logged on to the node. It is not
recommended that they are changed unless Tait Technical Support has
requested it. These parameters are read at startup and whenever the
command taitnet reload-cfg is executed. The file has to be edited by
a text editor such as ‘vi’.
If changes are made to node.cfg at one node, the same changes

must be made to the node.cfg file on all other nodes in the network
Only the parameter agw.groups should be modified by the customer

without Tait Technical Support recommendation:
agw.groups This is a list of which groups should be sent to the MPT gateway if enabled.
Groups are separated by a space. By default no groups are enabled.

7 Monitoring
7.1 Checking the Status of a Node
7.1.1 Using the Node

1. On the DMR web browser, select Network > Status for an overview
of the status of the various network elements.
2. Green signifies that the status of the network element is good.

Orange indicates a minor alarm and red indicates a major alarm.
3. To find out more, click a row. This takes you to a page that lists
elements of that type and allows you to view their configuration, and
in some cases, monitor their current operation.
7.1.2 Using an ssh Connection
If you are unable to access the Node you can manually check the status of
the node.
1. ssh into the node.
2. Depending on your node:

a. Version 4: enter docker exec -it tait_dmrnc bash,
followed by cd dmrnc, then enter ./taitnet status on the
command line. Enter exit to return to the Ubuntu host command
line.
b. Version 3: enter cd dmrnc, then enter ./taitnet status on
the command line.
c. Version 2: enter taitnet status on the command line.
3. You should see something like the following if the node is running
correctly:
$ taitnet status
Watchdog is running
Node is running
Packet Switch is running
4. If any of the processes are not running you should manually reset the
node (see “Resetting a Node” on page 188).
220 Monitoring Tait TN9300 DMR Tier 3 Trunked System Manual

7.2 Monitoring Calls
7.2.1 Call Records File Format
Call record files are saved in both comma separated file format (.csv) and
text file format (.txt).
Csv files The first line in the csv file contains the headings for the columns, and the
subsequent lines contain the values for each call record as follows:
Column name Description
uuid A string of 36 characters that uniquely identifies a call.

Sample: 46467d72-01fd-5a52-99fa-2942e5c15d1e
call_id A sequence number used for diagnostics
date_time A string containing the date and time the call was created.
The format is: YYYYMMDDThhmmssZ, where T and Z are
the characters T and Z.
a_party The calling party address encoded as an integer
b_party The called party address encoded as an integer
a_party_MPT 1327 The calling party address in extended MPT 1327 format
(prefix/ident). In MPT 1327 the prefix is restricted to the
range 0-127. The extended format allows prefixes in the
range 0-4196.
a_party_fleet The calling party address in fleet format
b_party_MPT 1327 The called party address in extended MPT 1327 format
(prefix/ident). In MPT 1327 the prefix is restricted to the
range 0-127. The extended format allows prefixes in the
range 0-4196. If the address is outside the MPT 1327
address range, or if it is a System ID (refer to Section 7.2.6
System IDs), the DMR number is displayed.
b_party_fleet The called party address in fleet format. If a System ID

name is listed, refer to Section 7.2.6 System IDs.
a_fleet_id The fleet ID for the calling party
b_fleet_id The fleet ID for the called party
sip_a_party_digits The calling party digits received from the SIP gateway for
telephone-to-radio calls
sip_b_party_digits The destination digits sent to the SIP gateway for radio-to-
telephone calls, or the digits received from the SIP gateway
for telephone-to-radio calls
call_type Refer to the table in Section 7.2.2 Call Types for a

complete list of call types
Tait TN9300 DMR Tier 3 Trunked System Manual Monitoring 221

call_priority The priority of the call:

0 - Normal Priority
1 - Priority 1
2 - Priority 2
3 - Priority 3
4 - Emergency
on_air_time The time in seconds that this call was on air.

For data calls that use only the control channel (UDTs),
on_air_time is the number of codewords used to transmit
the data, plus 1 (for the header codeword). For status calls,
where the status information is carried in a field within the
header codeword, on_air_time is always 1.
queue_time The number of seconds that the call waited for processing
(for example, the node was waiting for the radio’s IP
information during registration) or was queued due to lack
of channel resources
answer_time The time in seconds before this call was answered
end_reason Refer to the table in Section 7.2.3 Call End Reasons for a
complete list of call end reasons
handler_id Refer to the table in Section 7.2.5 Call Handler IDs for a
complete list of call handler IDs
line_id For handlers with multiple lines, this represents the line ID
supplemental_info Any supplementary information. For a base station, this is

the RF channel number. For DIP, this is the DIP sequence
number.
call_flags A bit field representing additional state information for the

call:
PRIORITY 0x00000002
The PRIORITY bit is set if the call is a high priority call.
EMERGENCY 0x00000004
The EMERGENCY bit is set if the call is an emergency
priority call.
LOCAL 0x00008000a
The LOCAL bit is set if the call is local to the site and
includes no other end points or sites.
OUTGOING 0x00010000
The OUTGOING bit is defined if the site or end point for this
call record receives the call. This is the inverse of the
ORIGINATING bit.
ORIGINATING 0x00020000
The ORIGINATING bit is set if the call originated from the
site or end point for this call record.
ENCRYPTED_OVER 0x0000400000000000
The PTT over was encrypted.
AMBIENT_LISTENING 0x0800000000000000
The call is an ambient listening call.
switch_node_id The ID (number) of the node that switched the audio for the
call. For calls that did not go to channel this will be 0.

switch_node_zone The switching zone assigned to the node that switched the
call
message The data sent in control channel data messages (status or

short data):
■ For status messages it will be the number value (from 1
to 127)
■ For short data messages, depending on the short data
type, it will be URL encoded copy of either the text sent,
or the raw binary data
a. For PTT overs, the LOCAL flag actually indicates if it is the called or call-
ing party transmitting. i.e. if the local flag is set, it means called party.
Txt files The text file can have one of two formats:
DateTime: 20110922T232728
CallId: 32a35de6-f9cc-6a51-a653-0e5a1385756b (00000012)
From: 200-2100-204 (00000204) To: 200-2100-209 (00000209) Digits:
OnAirTime: 00000004 QueueTime: 000 AnswerTime: 001
CallType: I CallPriority: 1 CallFlags: 00020000 EndReason: 021
Site/HandlerID: 0002 Channel/LineID: 002 (293)
SwitchingNodeID: 0004 SwitchingNodeZone: 0003
or
DateTime: 20110922T232728
CallId: 32a35de6-f9cc-6a51-a653-0e5a1385756b (00000012)
From: 200-2100-204 (00000204) To: 200-2100-209 (00000209) Digits:
OnAirTime: 00000004 QueueTime: 000 AnswerTime: 001
CallType: I CallPriority: 1 CallFlags: 00020000 EndReason: 021
Site/HandlerID: 0002 Channel/LineID: 002 (293)
Info: Site B, calling, normal, individual_voice, calling_party_clear
SwitchingNodeID: 0004 SwitchingNodeZone: 0003
The second format is produced if the resource file parameter

show_call_record_info is enabled. This adds an extra line of
information to each call record, which contains the decoded values for the
important fields like call type and call end reason. This creates a bigger file,
but is easier to decode by hand. By default this parameter is disabled, so
only the first format is used.

7.2.2 Call Types
The following table lists the possible call types and characters representing
those call types.
Type Description
A Authentication check
b Broadcast
B Bar unit
F Force registration
ga Regroup
G Group voice
I Individual voice and self test
K Kill unit
L Revive unit
m Group short data message
M Individual short data message
n Group packet data
N Individual packet data
p AVL poll
P Short data poll
R Registration
s Group status message
S Individual status message
T Call diversion
u Individual unit presence check
U USBD poll
W Status poll
x Cancel call
y Supplementary data
Y Stun unit
z ALLMSID

a. g is used for all affiliation call types (even if the groups are
not dynamically regrouped) - i.e. g is for both Regroup (dy-
namically regrouped) and/or Affiliations (radio affiliated)
7.2.3 Call End Reasons
This field contains a numeric code giving a detailed reason why the call
ended or failed. It is used to help diagnose configuration and equipment
faults.
Any call end reasons that have been generated by a TaitNet MPT net-
work (connected by a TN9500 Inter-Network Gateway) are identifiable
as they will be numbered as 1000 plus the TaitNet MPT call end reason.
Call end reasons generated by the TN9500 Inter-Network Gateway are
numbered as 2000 plus the call end reason. Refer to the TaitNet MPT
System Manual or TN9500 Installation and Configuration Manual for
their call end reasons.
The following table lists the number and name of each call end reason and
provides descriptions of them.
No. Reason and description
0 Unknown
The network was unable to establish why the call ended or failed
1 No call record required

Call records have not been enabled for this call
2 No control channel
The call was unable to be completed as there was no control channel available at the site to
handle this call request
3 Poll failed
A unit poll failed (either stun/revive/regroup/authentication)
4 Poll successful
A unit poll completed successfully (either stun/revive/regroup/authentication)
5 Calling party amalgamated

The calling party has been amalgamated into an existing call which has the same call type and
parties
6 Registration failed not allowed in service area

The calling party tried to register on a site outside of its configured service area, and was
denied service on this site
7 Registration accepted
The calling party registered at a site in its configured service area, and now has service on this
site
8 Called party diverted

This call ended because the called party is diverted
9 Calling party not registered

A call request was made, and rejected, at a site that the calling radio is not registered on

10 Calling party not validated for interfleet

The calling party attempted to make an interfleet call, but was rejected as it is not validated to
make interfleet calls
11 Calling party not validated for short data

The calling party attempted to send a short data message, but was rejected as it is not
validated to make short data messages
12 Calling party cancel

The call request was cancelled at the calling party's request, before the call was setup on
channel
13 Calling party not home

The call failed because the calling party became unavailable during a call setup and additional
information was required to setup the call (e.g. diversion information, interprefix address, short
data)
14 Calling party old call error

This call has failed because an existing call involving the calling party cannot be cleared to
make way for this new call attempt
15 Data self call not supported

Data calls to self are not allowed
16 Connecting timeout
The call has failed to connect all links in the call to an unexpected error elsewhere in the
system
17 Called party engaged

The called party is on another call
18 Called party not home

The called party is switched off or out of contact
19 Data successful
A data call on the control channel was successfully completed
20 Called party clear

The called party cleared down the call
21 Calling party clear

The calling party cleared down the call
22 Called not registered

The called party is not registered at any site
23 Calling not validated for diversion

The calling party is not able to make call diversions
24 Diversion clear accepted

A request to clear a diversion has been successful
25 Diversion set accepted

A request to set up a diversion has been successful
26 Called unsupported special ident

The call request was rejected because the calling party dialed an unsupported special ident
27 Diverted to unsupported party

The call attempt failed because it was diverted to a party that could not accept this call type.
This is either a status or short data message that was diverted to a phone number.

28 Calling not validated for status

The calling party is not set up to engage in status calls
29 Calling not validated for group

The calling party is not set up to engage in group calls
30 Calling not validated for emergency

The calling party is not set up to engage in emergency calls
31 Calling not validated for priority

The calling party is not set up to engage in priority calls
32 No valid channel partition

The call request failed as there is no valid channel partition that matches the call parties and
type. This means the call has no access to any of the traffic channels.
33 Timeout waiting for channel

The call has not gone through because the timeout period has expired whilst waiting for a free
channel
34 Maximum call link timeout

The call has completed successfully for the maximum call timeout
35 Stuck mute timeout

The call completed successfully, but the traffic channel was unable to be cleared because the
receiver on the base station has become stuck receiving audio. After the stuck mute timeout,
the channel was closed down despite the stuck receiver.
36 Timeout called party engaged

The call has not gone through because the calling party’s timeout period has expired whilst
waiting for the called party, who is on another call
37 Calling not validated for individual

The calling party is not set up to engage in individual voice calls
38 Called party rejected

The call did not proceed as the called party rejected the call request
39 Called party FOACSU unanswered

An incoming FOACSU call was not answered by the called party
40 Cleared due calling 2nd call

This call request was cleared down as the calling party has attempted to set up a second call
41 Call pre-empted channel

The call was cleared down early as the called or calling channel was pre-empted for an
emergency call
42 Call pre-empted party

The call was cleared down because either the called or calling party has been pre-empted.
Example: the called or calling party was wanted for an emergency call or a console call.
43 Channel failure
The channel carrying a call has failed, either due to a major fault (e.g. transmitter low forward
power alarm), or a communication loss to the channel. The call has been cleared down from
the system. However, as the channel is not working, it will be impossible to inform the radios
involved in the call.
44 Site overloaded
Call could not be set up because site is overloaded. The site can only process a certain
number of calls or messages at one time.

45 Unknown poll type

The poll type requested is not supported by the DMR system. This only becomes relevant
when linking system to another system which has more poll types.
47 Called rejected data

The called party rejected the data call
49 Called party does not exist

A call has been attempted to an address that has not been validated in the system
50 Calling party does not exist

An attempt has been made by a calling party that has not been configured in the system
51 Data to phone not supported

A status or SDM has been attempted to a PSTN or PABX, which is not supported in DMR
52 Calling not validated for phone

The calling party is not allowed to make calls to a telephone
54 No idle telephony gateways

The call failed as there were no SIP lines available for the outgoing phone call
55 Timeout waiting for site

The call timed out because one of or more of the sites in the call were unable to allocate a
traffic channel to the call
56 Authentication failed
The authentication check has failed
57 Authentication good
The authentication check is successful
58 No outphone table
An outgoing call to a PSTN or PABX failed because there is no outphone table set up for the
calling party
59 No outphone rule
An outgoing call to a PSTN or PABX failed because there is no outphone rule that meets the
criteria for the number the calling party has dialed
60 Call queue full

The call was unable to be queued because the maximum number of queued calls at the site
has reached the call queue limit. Note that 5 extra emergency calls can be made on top of the
configured queue depth.
61 Outphone digits not unit or group

The matching outphone table entry indicates that the call should be diverted, but the diverted
to party is not a valid unit or group address
62 Confirmed registration failed

The confirmed registration check has failed as the radio unit has not replied to the
authentication poll
63 Calling not validated for normal priority

The calling party is not set up for normal access level calls
64 Call authentication check failed

The system has been configured to perform authentication checks on call requests. The call
failed because the calling party has failed the authentication check.
65 Calling not validated for self call test

The call attempt was rejected as the calling party is not set up for self calls

66 Called not validated for phone

The incoming phone call was rejected as called party is not configured for PABX/PSTN calls
68 Calling party barred

The call attempt was rejected as the calling party has been barred from making or receiving
calls on the network
69 Called party barred

The call attempt was rejected as the called party has been barred from making or receiving
calls on the network
70 Called party not home diverted

The call to the called party has been diverted because the called party’s radio has been
switched off or is out of range, and has been configured for ‘divert on not home’
71 Called party busy diverted

The call to the called party has been diverted because the called party was busy, and has been
configured for ‘divert on busy party’
72 Calling party not validated for group NPD

The group non-prescribed data call request was rejected as the calling party is not configured
for group NPD calls
73 Calling party not validated for broadcast

The broadcast group call was rejected as the calling party is not configured for broadcast calls
74 Calling party not validated for individual NPD

The individual non-prescribed data call request was rejected as the calling party is not
configured for individual NPD calls
75 Group call amalgamated

This group call request was amalgamated in to an existing call to the same group
76 RCGA successful
The calling party has successfully requested a new group affiliation, or cleared its group
affiliation
77 RCGA failed
The calling party requested an invalid group affiliation, either with incorrect data in the SDM
request, or to a group that does not support group affiliation
78 Registration failed - already registered

The calling party tried to register, but that address is already registered to a special handler
(e.g. DIP connection), and the registration was denied
79 Calling party stunned

The calling party tried to make a call, but is not allowed as it is stunned
80 Called party stunned

The called party in a call is stunned, so the call attempt fails
81 PTT
A normal voice call over was completed
82 Call included
A call was included in another call at the site
83 PTT packet data

A packet data call over was completed
84 PTT emergency
An emergency voice call over was completed

85 Called not validated for NPD

The individual non-prescribed data call request was rejected as the called party is not
configured for individual NPD calls.
86 Calling not validated for ALL IDENT

The calling party is not validated to make ALL IDENT calls
87 Call request on non-control channel

A call request was received on a channel that was not a control channel, which can be as a
result of frequency re-use
88 Calling not in group fleet

The calling party has attempted to call, or affiliate to, a group that is not in its fleet.
89 Data format unknown

The data received from the terminal was in an unknown or unexpected format.
90 Control channel overloaded

Unable to send signaling as the control channel was overloaded.
91 Calling not validated for ALS

The calling party does not support ambient listening.
92 Called not validated for ALS

The called party does not support ambient listening.
100 SIP stack error

The request failed due to lack of resources or an incorrectly formatted SIP request
102 SIP called party clear

The phone call was cleared by the phone user hanging up the call in an outgoing phone call
103 SIP calling party clear

The phone call was cleared by the phone user hanging up the call in an incoming phone call
105 SIP line failed

The call was cleared because the SIP line used in a phone call has failed
106 SIP license exceeded

Exceeds the number of concurrent calls that can be made using SIP lines allowed under
license
110 SIP force clear group call

The group call has been cleared down by a called party on an SIP connection
120 AIS license exceeded

Exceeds the number of concurrent calls that can be made using AIS connections allowed
under license
121 AIS no transcoder available

The call could not proceed because there were no free transcoders available
140 ING license exceeded

Exceeds the number of inter-network connections allowed under license
202 Switch called not registered

The called party is not registered at any site
203 Switch individual unknown

The called party is not validated to be part of the system
204 Switch group unknown

The called group is not validated to be part of the system

205 Switch group invalid site

The calling party attempted to set up a group at a site that is not in the group service area
206 Switch called not ready

The called party link has failed to setup
207 Switch resource not available

The group call failed as there is no packet-switch available that can switch all the links
required, or a call from the TN9500 Inter-network Gateway has not proceeded due to expired
call queue timers with ‘Invite without SDP’ enabled
208 Switch transmission completed

This is a transmission trunked call, and the transmission has completed, so the call has
completed
209 Switch maximum call duration timeout

The call reached the maximum call limit and has been cleared by the node
210 Switch inactivity timeout

The packet switcher has detected no activity on any of the links in the call for the inactivity
period, so the call has been cleared down
211 Switch failure

The node has lost contact with the packet switcher switching the audio for this call, so has
closed down the call
212 Switch call unanswered

The call made it to channel but timed out because no one answered the call (i.e. transmitted).
300 DIP unsupported request

An unsupported call request has been sent from a dispatcher to the node. DMR does not
support all DIP messages.
301 DIP complete

The command issued from the dispatcher has been completed successfully by the node
302 DIP fail

The command issued from the dispatcher failed in the node
303 DIP including call not found

An include call failed because the including call could not be found
304 DIP including call invalid

An include call failed because the including call is not a valid call type for including, or was not
in the ‘connected’ state
305 DIP error

An outgoing call request to the dispatcher has failed, either due to a lost connection to the
dispatcher, or an unsupported call type
306 DIP called diverted

The dispatcher has diverted a call request made to it
307 DIP pre-empt

The call was pre-empted to clear a transcoder for an emergency call
308 DIP pilot answered by other DIP

This dispatcher link was cleared from a pilot call as the call was answered by another
dispatcher
309 DIP include call amalgamated

An include call was amalgamated to an existing call. The include call is no longer required.

310 DIP include call invalid

An include call failed because there is a problem with the call. Details have been printed to log.
311 DIP include party not home

An include call failed because the included party was ‘not home’
312 DIP force clear group call

A dispatcher can clear down a group call even if it is not the originator
313 DIP license exceeded

The number of calls exceeds the number allowed under license
314 DIP data too big

Packet data size is too big
315 DIP call back

The call terminated as DIP treated the call as a call back request
316 DIP no voice transcoder

The call could not proceed because there were no free voice transcoders available for use on
the network gateway assigned to the DIP connection
400 MPT gateway invalid party

The called or calling party in the call request from the MPT gateway is not a valid MPT address
401 MPT gateway maximum calls exceeded

The MPT gateway failed the call because it was already processing the maximum number of
calls
402 MPT gateway call already closed

The MPT gateway attempted to close a call that the DMR node believes has already been
cleared down
403 MPT gateway conflicting call

The call request from the MPT gateway has been rejected as DMR believes that there is
already a conflicting call in the system
404 MPT gateway downloading segment

Not all segments from a short data message have been received from the MPT gateway
405 MPT gateway called diverted

The call has failed because the call request from the MPT gateway is to a diverted party, but
there is no way to indicate diversions back through the MPT gateway
406 MPT gateway error

Unable to process an outgoing call request to the MPT gateway because the gateway has an
error, due to either the connection being lost or from invalid messages from the gateway
407 MPT gateway cleared

The MPT gateway has cleared down the call
408 MPT gateway data sent

All short data segments have been successfully sent to the MPT gateway
409 MPT gateway invalid type

The MPT gateway has sent an incoming call request to the DMR node which is unsupported
410 MPT gateway NGW failed

An MPT gateway call has failed as the network gateway assigned to the GCC to convert audio
has failed

500 CNV unsupported request

The call failed because the called party in an outgoing call to the conventional connection did
not match the individual or monitoring address configured for the conventional connection
502 CNV terminated

The call was unable to be set up on the conventional connection as it was already in a call, or
the network gateway used to convert audio for this call has failed
510 Deregistered by system

The deregistration was caused by the system (registration time-out)
511 Deregistered by user action

The deregistration was made from the node WebUI by selecting the Clear Registration button
512 Deregistered by ING

The deregistration was made by the TN9500 Inter-Network Gateway
550 Tone generator unsupported request

A call request of the wrong call type was made to the test tone generator
551 Tone terminated

Test tone call has completed
560 Local VR inactivity

The local voice recorder timed out for inactivity
561 Local VR auto cleared

The self test call automatically cleared the call after one PTT over
600 Reg failed illegal syscode

The registration failed because the syscode in the registration request didn’t match the control
channel syscode
601 Diversion IPV6 not supported

A radio attempted to divert itself to an IP v6 address, which is not supported currently
602 Deregistration accepted

The calling party de-registered at a site in its configured service area, and now no longer has
service on this site
603 Unsupported call type

The call request was not completed as the system does not currently support that call type
604 Short data poll to group illegal

The call request was rejected as you cannot poll a group
605 AVL poll failed

An AVL poll failed
606 AVL poll successful

An AVL poll was successfully returned
607 Called party not group

A group call was made to an individual address
608 Called party not individual

An individual call was made to a group address
609 Multipart diversions not supported

A voice-only, or data-only, diversion was attempted to be put in place. Tait only supports full
diversions (voice + data).
610 No packet data transcoder available

No packet data transcoder was available to carry out a DIP data call

611 DIP unexpected data

A data transaction was sent in a non-data call. Unable to process.
612 No sites affiliated with group

A group call was failed as there were no sites assigned for the group, either with service area,
or group subscription
614 IP registration accepted

The radio registered with an IP address and it was accepted
615 IP registration failed, already assigned

The radio tried to register with an IP address that was already in use by another radio
616 IP data, unexpected voice

The IP data gateway was sent a voice call
617 IP data, no free transcoder

The node has run out of data transcoders to handle this IP call
618 Calling not validated for IP data

The IP data call request was rejected as the calling party is not configured for IP data
619 Radio unit alarm successful

The radio has indicated an alarm by sending a status message, and it has successfully been
forwarded to the terminal alarm manager
620 Radio unit alarm failed

The radio has indicated an alarm by sending a status message, but the node was unable to
forward it to the terminal alarm manager
621 IP data not acknowledged

The radio did not acknowledge the packet data sent to it, so the call has been closed down
622 Registration accepted using existing IP

The radio registered, but used the existing IP address for the unit instead of getting it from the
radio
623 Registration accepted IP failed

The radio registered, but the IP address failed to be received from the radio
624 Include call not support data

Tried to include in a data call
625 IP deregistration accepted

Radio has deregistered its IP address
626 Transmit interrupt not supported

Transmit interrupt status calls (AKA payload interrupt) are not supported
627 IP data packet too long

A data packet is longer than IP Data > maximum packet data size and the DF (don't fragment)
bit is set
628 IP data packet queue full

A data packet was discarded because the data packet queue is full
629 IP data unit has no IP address

A valid data packet was received, but could not be sent because the unit had not registered an
IP address
630 IP data not supported service

A unit with a fleet-assigned IP address cannot support general IP data packets

631 Group attachment not supported

Node does not support group attachment
632 Transmit interrupt

A unit is attempting to interrupt a talking user, and has been accepted by the node as a valid
interrupt. The called party will be sent an interrupt request, but it may not actually accept the
interrupt.
633 Transmit interrupt - no existing call

A transmit interrupt was requested, but no relevant existing call was on channel that could be
interrupted
634 Transmit interrupt - talking not interruptible

The talking party is not allowed to be interrupted
635 Transmit interrupt - call not interruptible

The call to be interrupted cannot be interrupted at this point in time
636 Transmit interrupt - too soon after last interrupt

A transmit interrupt request has happened too soon after a previous interrupt in the call
637 Transmit interrupt - call closing

A transmit interrupt has been rejected as the call is about to close, or is now in a closing down
state, so no new PTTs are wanted in the call
638 No alternate channel

The call was unable to be completed as there was no alternate channel available at the site to
handle this call request
639 Registration accepted group attachment

The group attachment registration was accepted.
640 Registration accepted attach fail busy

The group attachment registration was accepted, but the group list failed to be loaded from the
unit because the system was busy.
641 Ambient listening not supported

Node does not support the ambient listening feature
642 Full duplex not supported

Node does not support full duplex individual voice or packet data call requests
643 Registration accepted attach fail upload

The group attachment registration was accepted, but the group list failed to be loaded from the
unit because it did not reply, or it sent the wrong reply.
644 Registration accepted attach fail groups

The group attachment registration was accepted, but not all groups were accepted as the unit
was not allowed to attach.
645 Dynamic regrouping list invalid

The list of groups for dynamic regrouping either exceeded the limit of 15, or contains at least
one invalid address.
646 Tx interrupt call terminate

The transmit interrupt to terminate a call was successful
647 Tx interrupt call terminate invalid

The transmit interrupt to terminate a call was not processed, as the party was not allowed to do
this
648 Tx interrupt call terminate no call

The transmit interrupt to terminate a call was not processed, as there was no existing call

649 Call preempted control channel allocation

The call was cleared down early as the channel is being allocated as a control channel
700 AIS heartbeat expired
701 AIS unit registration failed

A registration for an AIS unit for the TN9500 gateway (or Tait TeamPTT) failed.
702 AIS unit deregistration failed

A deregistration for an AIS unit for the TN9500 gateway (or Tait TeamPTT) failed.
710 AIS message data has no content
711 AIS message data is too big
712 AIS message data not supported
713 AIS force clear group call

The group call has been cleared down by a called party on an AIS connection
800 Emergency alarm acknowledged

Emergency alarm request acknowledged
801 Emergency alarm canceled

Emergency alarm cancel acknowledged
900 TeamPTT force clear group call

The group call has been cleared down by a called party on a TeamPTT connection
7.2.4 Call Close Reasons
This field contains a numeric code giving a detailed reason why the call
closed.
The following table lists the number and name of each call close reason and
provides descriptions of them.
1 TE BUSY
The called party is busy
2 SYS_BUSY
The DMR system is too busy for this call
3 REJECTED
The called party rejected the call
4 NOT_HOME
Called party could not be found
5 COMPLETE
Cleared, completed, accepted
6 CALL_BACK
Queued in the radio for callback

7 INVALID
Call rights / service type failure
8 PREEMPT
The call link wants to pre-empt the call
9 AMALGAMATED
Call has been amalgamated into a group
call
11 DIP CALL AMALGAMATED

DIP call has been amalgamated into a
group call
99 UNKOWN
The call has closed for an unknown reason
7.2.5 Call Handler IDs
Each link in a call is stored as a call record. The handler ID number

identifies the link type, as follows:
■ Site: Site ID
■ SIP lines: 1000
■ AIS and inter-network (INP) connections: 1000 + ID
■ Tait TeamPTT connections: 1700 + ID
■ DIP connections: 2000 + DIP connection ID
■ MPT gateway: 4000 + MPT gateway line ID
■ Conventional connections: 5000 + Conventional connection ID
■ AVL monitor: 8000
■ Group affiliation: 8002
■ IP data gateway: 8003
■ Terminal alarm manager: 8004
■ Tait info monitor: 8006
■ Emergency alarm auto acknowledger: 8008
■ Presence checks: 9999
Note that ID is the allocated number as displayed in the ID column on

the relevant WebUI page.
7.2.6 System IDs
System ID’s are addresses used in signaling over the air when making calls
to and from the special gateways, rather than to an individual or group (e.g.
phone calls).

System ID Hex Decimal Description
ALLMSI 0xFFFED4 16776916 The totality of all individual MS and talkgroups (used in
Clears only)
ALLMSID 0xFFFFFF 16777215 ID used to address all MS (AllCall) in every site in the
system as a talkgroup
ALLMSIDL 0xFFFFFD 16777213 ID used to address all MS at one site as a talkgroup
ALLMSIDZ 0xFFFFFE 16777214 ID used to address all MS in a subset of the system’s

sites as a talkgroup
ALLTALKGROUP1 0xFFFFF0 16777200 Address for talk groups 1 to 9

... ... ...
ALLTALKGROUP9 0xFFFFF9 16777209
AUTHI 0xFFFECD 16776909 Authentication Identifier
DISPATDI 0xFFFED3 16776915 Address of the system dispatcher using payload offset
timing
DISPATI 0xFFFECB 16776907 Address of the system dispatcher using payload

aligned timing
DIVERTI 0xFFFEC9 16776905 Address used to identify a call diversion cancellation
DUMMYI 0x000000 0 Used in data call destination address. The reason is

that the Rx activity report sent from the base station at
the start of an over only includes LC headers and not
packet data headers. This means the channel
controller only knows the source and destination
addresses for voice calls, not data calls. In voice calls,
the channel controller only knows who is talking as it
extracts the calling party address from the DMR stream
information in the VDP protocol. In data calls, the
channel controller has no way of easily getting the
called party without fully decoding the DMR headers in
the packet switcher. This would cause too much
overhead in the packet switcher.
GPI 0xFFFECE 16776910 Talkgroup Identifier
IPDI 0xFFFED5 16776917 Address for services to an IP gateway using payload

offset timing
IPI 0xFFFEC3 16776899 Address for services to an IP gateway using payload

aligned timing
KILLI 0xFFFECF 16776911 MS KILL Identifier
LINEDI 0xFFFED2 16776914 Address for services to a Line Gateway using payload
offset timing
LINEI 0xFFFEC2, 16776898 Address for services to a Line Gateway using payload
aligned timing
MSI 0xFFFEC7 16776903 Address used to identify the totality of individual MS

address space
PABXDI 0xFFFED1 16776913 Gateway address for services to the PABX using
payload offset timing

System ID Hex Decimal Description
PABXI 0xFFFEC1 16776897 Gateway address for services to the PABX using
payload aligned timing
PSTNDI 0xFFFED0 16776912 Gateway address for services to the PSTN using
payload offset timing
PSTNI 0xFFFEC0 16776896 Gateway address for services to the PSTN using
payload aligned timing
REGI 0xFFFEC6 16776902 Address used to identify a registration service
SDMI 0xFFFEC5 16776901 Address used to identify a UDT short data service
STUNI 0xFFFECC, 16776908 MS Stun/Revive Identifier
SUPLI 0xFFFEC4 16776900 Address used to identify a supplementary data service
TATTSI 0xFFFED7 16776919 Address to identify the Talkgroup Subscription/

Attachment Service
TGI 0xFFFEC8 16776904 Reserved
TSI 0xFFFECA 16776906 Address of the TS
Tait specific Addresses:
GASI 0xFFFED5 16776917 TAIT PROPRIETARY - for group affiliation service

DMR Specification pre-version 1.5.1
GASI 0xFFFEF3 16776947 TAIT PROPRIETARY - for group affiliation service

DMR Specification version 1.6.1 or later
SELF_CALL 0xFFFFEF 16777199 Used for self calls in Tait systems
TAIT_DIAGNOSTICS_ 0xFFFEF1 16776945 Diagnostic poll identifier

POLL_GATEWAY
TAIT_INFO_POLL_ 0xFFFEF0 16776944 Information poll identifier - referred to as INFOI in call

GATEWAY records (info refers to action taken e.g. unit alias
change /update etc)
TAIT_LOCATION_ 0xFFFEF2 16776946 Location poll identifier

POLL_GATEWAY
TERMINAL_ALARM 0xFFFFEE 16777198 Radio alarm

7.3 Investigating Alarms
Alarms can be viewed in the node’s WebUI (Network > Alarms) and alarm
files can be downloaded from the node and used for troubleshooting
purposes. Alarms can also be sent by SNMP to an SNMP manager (see
EnableMonitor Getting Starting Guide (MNE-00001-xx) for more
information).
7.3.1 Alarm File Format
Alarm files are named alarms-<YYYYMMDD>.csv, where YYYY is the

year, MM is the month and DD is the day.
Each alarm message in the alarm log file consists of a string of ASCII
characters in comma-separated fields, terminated by the Enter character.
Each alarm entry has the following fields:
1. Date/Time
The Date/Time is represented as ISO8601 format of YYYYMMD-
DThhmmssZ where:
■ YYYY indicates a four-digit year, 0000 through 9999
■ MM indicates a two-digit month of the year in the range 01
through 12
■ DD indicates a two-digit day of that month in the range 01
through 31
■ hh indicates the hour between 00 and 23
■ mm refers to the minute between 00 and 59
■ ss refers to the second between 00 and 59
2. Alarm Severity (displayed in WebUI only)

There are three levels of alarm severity:
■ Red - Major
■ Yellow - Minor
■ Green - OK
For example, a major channel alarm will remove a channel from ser-
vice, whilst a minor channel alarm will make it least preferred for
traffic duties, however will cause no change for control channels.
OK indicates that an alarm has been cleared.
3. Alarm Type
This is the number of the alarm raised (see table below for alarm
types and details).
4. Alarm Details
These are the details of the alarm raised (see table below for alarm
types and details).

Alarms raised by the Channel Group Manager are also recognized by
the node.
7.3.2 Network Alarms
The following is an explanation of the terms used in the Alarm Detail

column of the table below:
■ address - the MPT 1327 address of the connecting device (the MPT
1327 address is in the format ppp/iiii - where ppp represents the prefix
and iiii the ident of the connecting device)
■ bs - the channel ID as displayed by the site status page
■ channel - the channel number
■ count - indicates the number of control channels:
■ 00 - no control channel
■ 01 - one control channel (if you have a count of one but a ‘failed’
message, the site is expected to have dual control channels)
■02 - dual control channels
■ file-name - the database file name
■ id - the node number
■ ip - the IP address of the network element
■ link - the link direction between the base station and the radio:
■ Rx indicates uplink from radio to base station
■ Tx indicates downlink from base station to radio
■ node - the node number
■ number - the ID of the DIP connection
■ port - the digital inputs on the DB9 connector of the base station
■ site - the site ID starting from 1
■ tbl-name - the database table name
■ user - the SIP username
Alarm Alarm
Alarm Detail Name and description
Type Severity
0 Unknown OK
Alarm type is unknown
2 site=<int>:bs=<int> Channel down

Major
A link to a base station has failed
8 site=<int>:bs=<int> Channel minor alarm

A base station is indicating a minor alarm condition. Minor
This is often generated on low forward power.
9 site=<int>:bs=<int> Channel major alarm

A base station is indicating a major alarm condition. Major
This is often generated on high reverse power.

Alarm Alarm
Type Severity
11 channel=<int> Stuck mute alarm

A traffic channel still detects RF signal after a call Minor
has closed
13 site=<int> Site down

Major
The site has no control channels assigned
14 site=<int> Site up
The site has exited the ‘site failed’ state because at OK
least one channel has returned to service
19 Low disk space Major
20 address=<int> Authentication good OK
21 address=<int>:status=<int> Authentication failed Minor

Status field values are:
0: None - authentication failed by unknown reason
1: Polling - authentication is on processing
2: FailedNotHome - called party could not be found
or has not replied
3: FailedBusy - called party is busy, or the unit or
system is busy
4: BadAuthentication - authentication failed
5: BadCrcReceived - authentication failed by CRC
(not used)
6: GoodAuthenticationReceived - authentication
successful
7: Rejected - called party rejected authentication
8: NotRegistered - authentication failed for radio not
registered or call rights
26 site=<int>:bs=<int>:port=<int> Channel digital input set

A digital input has been activated on a network OK
gateway or base station
27 site=<int>:bs=<int>:port=<int> Channel digital input clear

A digital input has been deactivated on a network OK
gateway or base station
32 site=<int>:bs=<int> Channel up
The node has established a connection to a OK
previously failed base station
40 user=<text>:ip=<text> SIP line up

OK
The node has established a connection to a SIP line
41 user=<text>:ip=<text> SIP line down

Major
The node has lost a connection to a SIP line
42 number=<int>:address=<text> DIP connection up

OK
The node has established a DIP connection
43 number=<int>:address=<text> DIP connection down

Major
The node has lost a DIP connection
46 License check failed

Indicates that there is no license, or that the license Major
is invalid or expired

Alarm Alarm
Type Severity
47 site=<int>:count=<int> Site control channel failed

Major
The site has fewer control channels than it should
48 ip=<text> Network failure

One of the network check addresses is not Minor
responding to ping queries
49 Network up
The network check addresses are responding to OK
ping queries
50 ip=<text> Node activated

OK
The node has entered control mode
53 site=<int>:bs=<int>:port=<int> Channel output set

A digital output has been activated on a network OK
gateway or base station.
54 site=<int>:bs=<int>:port=<int> Channel output cleared

A digital output has been deactivated on a network OK
gateway or base station.
55 site=<int>:bs=<int>:
Channel jammed Minor
channel=<int>
56 site=<int>:bs=<int>:
Channel unjammed OK
channel=<int>
58 ip=<text> Remote node link up

OK
A remote node connection has been established
59 ip=<text> Remote node link down

Major
A connection to a remote node has been lost
60 ip=<text> Network gateway up

A connection to a network gateway has been OK
established
61 ip=<text> Network Gateway down

Major
A connection to a network gateway has been lost
62 site=<int>:bs=<int> Base station license check failure Major
63 site=<int>:bs=<int> Base station license check OK

This alarm is only generated if a base-station license OK
check has failed, and then subsequently succeeds
64 address=<int> Terminal alarm

This alarm indicates the alarm originating radio unit
and the type of radio unit alarm. Refer to
Section 7.3.3 Radio Unit Alarms for a complete list
of radio unit alarms.
65 ip=<text> MPT gateway up

The node has established a connection to an MPT OK
gateway
66 ip=<text> MPT gateway down

Major
A connection to an MPT gateway has been lost
67 site=<int>:bs=<int> Control channel entered temporary traffic mode

OK
The site has entered temporary traffic mode

Alarm Alarm
Type Severity
68 site=<int>:bs=<int> Control channel exited temporary traffic mode

OK
The site has exited temporary traffic mode
69 id=<int>:ip=<text> Remote node synchronization failed Major
70 id=<int>:ip=<text> Remote node synchronization recovered OK
71 address=<int> Deregistered by system

The radio has been automatically deregistered by
Minor
the system, due to inactivity during the timeout
period
72 site=<int>:bs=<int>: Channel Tx overloaded

Minor
channel=<int> The channel’s Tx audio buffer is overloaded
73 site=<int>:bs=<int>: Channel Tx overloaded

OK
channel=<int> The channel’s Tx audio buffer is overloaded
74 user=<text>:id=<int>:
Tait TeamPTT link up OK
ip=<text>
75 user=<text>:id=<int>:
Tait TeamPTT link down Major
ip=<text>
76 site=<int>:bs=<int>: Channel utilization upper threshold

channel=<int>:link=<text> The control channel utilization has reached the Minor
configured raise-alarm threshold
77 site=<int>:bs=<int>: Channel utilization lower threshold

channel=<int>:link=<text> The control channel utilization has reached the OK
configured clear-alarm threshold
78 id=<int>:ip=<text> Packet switch link overloaded

The packet switcher has detected an overloaded Major
audio link and is discarding RTP packets
79 id=<int>:ip=<text> Packet switch link overload cleared

The packet switcher overload link alarm has been OK
cleared
80 ip=<text> Packet switch protocol mismatched

The packet switcher has detected a protocol version Major
mismatch
81 ip=<text> Packet switch protocol mismatch cleared

The packet switcher protocol version mismatch OK
alarm has been cleared
82 id=<int>:ip=<text> Packet switch link fully used

The packet switcher has detected that an audio link Minor
is fully used
83 id=<int>:ip=<text> Packet switch link fully used cleared

The packet switcher audio link fully used alarm has OK
been cleared
84 tbl-name=<text> Database table access failed

Major
Access to the database table failed
85 tbl-name=<text> Database table access failure cleared

OK
The database table access alarm has been cleared

Alarm Alarm
Type Severity
86 file-name=<text> Database file access failed

Access to the database failed, or the database table Major
cannot be identified
87 file-name=<text> Database file access failure cleared

OK
The database file access alarm has been cleared
7.3.3 Radio Unit Alarms
Some radio equipment can be configured to send status messages to a

special address which is used as Terminal Alarm Manager by the node
controller. To enable this, customized Tait equipment (i.e. an MCP/VTC),
external to the radio hardware itself, is required. The node controller checks
for the status messages sent to this special address from the radios and
sends SNMP traps that correspond to the status values. The special address
is configured in the configuration file1 by setting the
dmr_special_ident.terminal_alarm field to the DMR address to be
used.
Status
Alarm
Message Alarm Detail Name and description
Severity
ID
64 address=<int> PPP link to MCP down Major
66 address=<int> GPS signal lost Minor
67 address=<int> GPS signal regained (after loss) OK
68 address=<int> Terminal antenna connection failure (VSWR out of

Major
range)
69 address=<int> Terminal antenna connection good OK
70 address=<int> Terminal supply voltage out of range Major
73 address=<int> Terminal temperature T0 (normal range) OK
74 address=<int> Terminal temperature T1 (over temp) Minor
75 address=<int> Terminal temperature T2 (over temp) Major
76 address=<int> Terminal temperature T3 (over temp) Major
77 address=<int> Terminal loss of service Minor
78 address=<int> Terminal unsolicited reset Minor
80 address=<int> Radio frequency out of lock (service regained) Major
81 address=<int> Terminal gained service OK
82 address=<int> MCP configuration error Major

7.4 Monitoring Statistics
The node records statistics for all base stations and sites and stores them for
90 days. There are several types of statistic recorded that can be accessed
from Files > General Statistics:
■ Site statistics
These are general statistics such as how many channels are available
at the site, or how many channels have been in use, together with
general alarms.
■ Channel statistics
For every channel, detailed statistics are recorded indicating infor-
mation such as the number of times the channel has been used, and
the number of messages sent on each interface.
■ Process
For each node process, a statistics file is produced. These are gener-
ated from different files in the process files generated by the OS.
These statistics will be different depending on the OS the node is
running on.
■ CPU/Memory
Records memory use and CPU statistics for each node process run-
ning.
■ USBD Poll
Records statistics for each alternate channel.
■ Inter-network
Records usage statistics for each inter-network link.
■ Packet Data
Records the number of data packets sent or received, and how many
were successful or failed, in the last 30s period.
■ API (this includes API Statistics and API Detailed Statistics)
Keeps track of the total number of requests on the monitoring API,
every 30s. Including how many requests were successful, queued, or
failed.
■ File
Records information on the size of files and folders used by the node
controller.
■ CC Queue
For each control channel in the network, there is a statistics record
written every 30 seconds.
A more detailed description of the site and channel statistics is given below.
For details on the other statistics files, refer to the online help under Files
> General Statistics.

Statistics information is saved every 30 seconds to a file stored on the node.
Two new statistics files are created every day; one for the sites and one for
for the channels. The files are kept for up 90 days on the node.
Each file is labeled with the date that the statistics were recorded for, and
is written in a comma separated file (.csv) format that allows it to be
imported to Microsoft Excel, or viewed on a text editor. The simplest way
to download statistics is to select the appropriate file on your web browser
attached to the node. The files can also be manually downloaded from the
node by using a utility such as ‘scp’ to copy the statistics files from the The
statistics parameters are generally one of two types of parameters:
1. Absolute value: this is the actual real time value at the time the
record was written, and is generally what is displayed on the status
screens on the node.
2. Running total: these are the total values, or times, since startup of the
node and are accumulated over time. They are reset every time the
node is restarted.
7.4.1 Site Statistics
These statistics monitor functional site performance only; satellite sites

are not taken into account.
The site statistics file is written to every 30 seconds. It is a comma

separated file (.csv), containing the following columns:
Column Description
date_time Time the record was written
site Site number for the site these statistics are produced for
enabled Number of channels enabled at the site at this point in time
disabled Number of channels that have been disabled at the site at this
point in time
minor Number of channels with a minor alarm at this point in time
major Number of channels with a major alarm at this point in time
cc Number of control channels at this point in time
tc Number of traffic channels at this point in time
idle Number of idle channels at this point in time
fail Number of failed channels at this point in time
queued Number of calls queued for channel at this point in time
on_air Number of calls on air for this site at this point in time
ringing Number of calls in a ringing or setup phase (not queued) at this

point in time

Column Description
cc_busy_tx Total number of transmit codewords used by the control channel

for call setup signaling on the control channels since startup
cc_busy_rx Total number of received codewords on the control channels since

startup
cc_idle_tx Total number of transmit slots not used by the control channels
since startup
cc_idle_rx Total number of received slots not used on the control channels
since startup
total_calls Total number of calls processed by the site since startup
chan_callsa Total number of calls that requested traffic channels (i.e. voice or
data) since startup. They may not have gone to channel.
t_queue Total time of queueing for all calls since startup, in seconds
t_cc Total time in seconds that channels have been control channels
since startup
t_tc Total time in seconds that channels have been traffic channels
since startup
t_idle Total time in seconds that channels have been idle since startup
t_fail Total time in seconds that channels have been failed since startup
Q_0s Number of calls that were queued for less than 5 seconds since
startup
Q_5s Number of calls that were queued for between 5 and 10 seconds
since startup
Q_10s Number of calls that were queued for between 10 and 20 seconds
since startup
Q_20s Number of calls that were queued for 20 seconds or more since
startup
ac Number of alternate channels at this point in time
t_ac Total time is seconds that channels have been alternate channels
since startup
a. Note that this represents all requests made for a traffic channel, including those
that did not result in a call being made.
The following calculations are examples of the type of information that can
be gathered from the statistics files, and are used in both the Daily Site
Details report and the Daily Site Summary report (Section 7.5). These may
help to determine when more channels or sites are required.
1. Site channel availability (average number of channels available for

use over a period):
(t_cc[diff] + t_tc[diff] + t_idle[diff]) / (period)

2. Site channel reliability (percentage of time that channels have been
working (i.e. not failed), over a period):
100 * (t_cc[diff] + t_tc[diff] + t_idle[diff]) / (t_cc[diff] + t_tc[diff] +
t_idle[diff] + t_fail[diff])
3. Traffic channel utilization (percentage time traffic channels have

been in use over a period):
100 * t_tc[diff] / (t_tc[diff] + t_idle[diff])
4. Grade of service (average time each call is queued over a period of

time)2:
t_queue[diff] / chan_calls[diff]
5. Control channel utilization (percentage of slots that the control

channel used for call setup signaling):
(cc_busy_tx[diff] + cc_busy_rx[diff]) / (cc_busy_tx[diff] +
cc_busy_rx[diff] + cc_idle_tx[diff] + cc_idle_rx[diff])
See the description of control channel utilization in Section These

reports are generated using data from the site statistics files, Daily Site
Summary Report for information how this data is gathered.
7.4.2 Channel Statistics
The channel statistics file is written to every 30 seconds, with a one line
record for every enabled channel in the system. It is a comma separated file
(.csv), with the following columns:
Column Description
date_time Time the record was written
site Site number of the base station
chan Channel number of the base station at the site
rf RF channel number
bsp_rx Total number of control messages (BSP) received from the

base station
bsp_tx Total number of control messages (BSP) sent to the base

station
bsp_lost Total number of control messages (BSP) detected to have

been lost from the base station
rtp_rx Total number of voice packets (RTP) received from the

base station at the node
2. Note that queue times also include the time that the node has to wait when
receiving registration or group affiliation information from radios.

Column Description
rtp_tx Total number of voice packets (RTP) sent to the base

station from the node
rtp_loss Total number of voice packets (RTP) detected to have been

lost between the base station and node
rtp_ping_rtt Average Round trip time (RTT) in milliseconds to send a

voice packet (RTP) and receive a response from a base
station
rtp_ping_jitter Maximum Jitter time (ms) in the last 10 seconds. The jitter
indicates the time difference from when we expected an
RTP packet to arrive, to when it actually arrived.
it_rqsea Total incoming RQS or RQE codewords - voice
im_rqsea Maximum incoming RQS or RQE codewords
it_rqrta Total incoming RQR or RQT codewords (registration or

diversion)
im_rqrta Maximum incoming RQR or RQT codewords
it_rqqca Total incoming RQQ or RQC codewords (status or SDM)
im_rqqca Maximum incoming RQQ or RQC codewords
it_acka Total incoming ACK or SAMIS codewords received
im_acka Maximum incoming ACK or SAMIS codewords received
it_hdcwa Total incoming HEAD or DCW codewords received (data)
im_hdcwa Maximum incoming HEAD or DCW codewords received

(data)
ot_gtca Total outgoing GTC codewords (go to channel)
om_gtca Maximum outgoing GTC codewords
ot_acka Total outgoing ACK codewords (acknowledgements)
om_acka Maximum outgoing ACK codewords
ot_ahya Total outgoing AHY codewords (Ahoys)
om_ahya Maximum outgoing AHY codewords
ot_hdcwa Total outgoing HEAD or DCW codewords (data)
om_hdcwa Maximum outgoing HEAD or DCW codewords
ot_filla Total outgoing filler codewords (i.e. unused slots)
om_filla Minimum outgoing filler codewords
failed Total seconds channel has been in failed state since startup
traffic Total seconds channel has been in use for traffic since
startup
control Total seconds channel has been in use for control since
startup

Column Description
idle Total seconds channel has been idle since startup
alternate Total seconds channel has been in use as an alternate

channel since startup
a. The codeword statistics indicate how busy a channel is made by the sending or
receiving of different FFSK codewords.
The statistics that come from the base station count the number of slots that were
used to send a particular codeword, not codewords. This is important for data
codewords (DCW) where there are either 1 or 2 codewords in a slot. In either case
it will indicate that 1 slot was used.
These statistics can be used to work out how busy a control channel is. For each
type of codeword that is received or transmitted we have two counters:
1. Maximum: the maximum number of that codeword type that were transmitted
or received in one second, during the last 10 seconds
2. Total: the total number of each codeword type transmitted or received since
startup.
7.5 Monitoring Site Performance

These statistics monitor functional site performance only; satellite sites
are not taken into account.
The node produces daily reports of site performance. There are two reports
generated for each day:
■ DailySiteSummaryReport-YYYYMMDD.pdf
■ DailySiteDetailsReport-YYYYMMDD.pdf
Where YYYYMMDD represents the date to which the report pertains.
These reports are generated using data from the site statistics files, Daily
Site Summary Report
This report is in the form of a table with the following columns:
Report Column Description
Site ID The site ID
Number of Average number of channels operating during the day. A

Channels value that is not a whole number (i.e. containing a decimal
point) indicates that the number of operating channels
changed at some point during the day.
Control Channel The percentage of time that a control channel was

Availability operating. A value of less than 100% indicates that the
control channel was failed for at least part of the day.

Traffic Channel The percentage of time that the traffic channels were not in
Availability a failed state. Traffic channels can be in one of three
modes: idle, carrying traffic and failed.
To calculate Traffic Channel Availability, we sum the

number of seconds that all traffic channels were idle or
carrying traffic. We then divide this by the number of
seconds that traffic channels were idle, carrying traffic or
failed.
Control Channel The percentage of time that the control channel(s) were
Utilization busy.
To calculate Control Channel Utilization, we sum the

number of packets received or transmitted by the control
channel(s) whilst busy. We then divide this by the total
number of packets received or transmitted by the control
channel(s).
Note: If all base stations in a site are removed for a certain

period of time, the node will stop generating data for them
as they are no longer connected. If the base stations are
added back to the site (if a database is restored or
manually created) on the same day, the node will reset the
values of cc_idle_tx and cc_idle_rx to 0. The control
channel utilization calculation at this point will measure at
100% utilization for one hour until the values of the cc_idle
parameters (cc_idle_tx and cc_idle_rx) are updated with
the correct values. This means that the control channel
utilization average and hourly value (in the in the Daily Site
Details report) will be inaccurate.
Traffic Channel The percentage of time that the channels that were not in a
Utilization failed state were operating in traffic mode.
To calculate Traffic Channel Utilization, we sum the number

of seconds that all traffic channels were carrying traffic. We
then divide this by the number of seconds that traffic
channels were idle or carrying traffic.
Control Channel The total number of calls carried on control channels

Calls summed over the day. These are data calls such as SDM
and status messages, which do not require a traffic
channel.
Traffic Channel The total number of calls that requested traffic channels
Calls (i.e. voice or data) for the day. They may not have gone to
channel.
Busy Hour/Start The time at which the busy hour started. The busy hour is
Time the 60 minute period during which the most calls were
made.
Busy Hour/Traffic The same as Traffic Channel Utilization (see above) but for
Channel Utilization the busy hour, rather than for the whole day
Busy Hour/Control The same as Control Channel Utilization (see above) but
Channel Utilization for the busy hour, rather than for the whole day

Busy Hour/Traffic The same as Traffic Channel Calls (see above) but for the
Channel Calls busy hour, rather than for the whole day
Busy Hour/Control The same as Control Channel Calls (see above) but for the
Channel Calls busy hour, rather than for the whole day
Busy Hour/GoS > A measurement of the grade of service (GoS) at the site.
5s This is the percentage of calls that were queued (waiting for
a traffic channel) for over 5 seconds. This is measured
during the busy hour.
Busy Hour/GoS > A measurement of the grade of service at the site. This is
20s the percentage of calls that were queued (waiting for a
traffic channel) for over 20 seconds. This is measured
during the busy hour.
7.5.1 Daily Site Details Report
This report is in the form of a series of graphs. Each site on the network has
two graphs, one for the control channel and one for the traffic channels.
Each graph shows the traffic/control channel utilization at the site as

measured every 15 minutes.
7.6 Monitoring IP Links

You can check that the node you are currently logged on to is connected to
other network elements:
1. On the DMR web browser, select Settings > Local Parameters.
2. Enter up to two IP addresses of any network elements in the Network

check A IP address and Network check B IP address fields.
3. Click Save.
4. In the Network check status fields, a green circle and ‘OK’ is

displayed if the node can connect to the network element identified
in the IP address fields. A red circle and ‘Failed’ indicates that the
node has been unable to connect to the specified network element. A
grey circle indicates that no network element IP address has been
entered.
The node will check its connection to the identified network element(s)
every 10 seconds. When only one network element’s IP address has been
entered, if the connection fails, then the node will automatically change
from control to switching mode. If two network elements IP addresses have
been entered, the node will remain in control mode if one connection has
failed, but if both connections fail, the node will change from control mode
to switching mode.


MNB-00003-29 - User Manual Tait DMR Tier 3

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

MNB-00003-29 - User Manual Tait DMR Tier 3

Uploaded by

Copyright:

Available Formats

Tait TN9300 DMR

Tier 3 Trunked Network

MNB-00003-29 · Issue 29 · October 2022

Enquiries and Comments

2 Tait TN9300 DMR Tier 3 Trunked System Manual

Tait TN9300 DMR Tier 3 Trunked System Manual Contents 3

3 Network Features and Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4 Contents Tait TN9300 DMR Tier 3 Trunked System Manual

4 Fleet Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Tait TN9300 DMR Tier 3 Trunked System Manual Contents 5

6 Contents Tait TN9300 DMR Tier 3 Trunked System Manual

Tait TN9300 DMR Tier 3 Trunked System Manual Contents 7

8 Contents Tait TN9300 DMR Tier 3 Trunked System Manual

Tait TN9300 DMR Tier 3 Trunked System Manual Contents 9

This alert is used to highlight significant information that may be

10 Preface Tait TN9300 DMR Tier 3 Trunked System Manual

Technical Notes are also published from time to time to describe

Acronyms and Definitions

AAA Authentication, Authorization, Accounting - standard feature

AES Advanced Encryption Standard

AIS Application Interface Support

ALS Ambient Listening Service

AMBE+2 Half-rate advanced multiband excitation vocoder

ANN Algorithmic Network Numbering - a numbering scheme used

API Application Programming Interface

ARC4 Alleged Rivest Cipher 4 - a simple encryption / decryption

BOOTP Boot protocol - facilitates booting devices (clients) from a

Tait TN9300 DMR Tier 3 Trunked System Manual Preface 11

DES Data Encryption Standard

DHCP Dynamic Host Configuration Protocol - allows a host to

DIP Dispatcher Interface Protocol - used for making dispatcher-

DMR Digital Mobile Radio - an open radio standard

DSCP Differentiated Services Code-Point - a field in the IP header

FEC Forward Error Correction - a redundancy technique used to

FFSK Fast Frequency Shift Keying - the modulation used in MPT

FGN Fleet Group Number (DMR standard numbering scheme

FIN Fleet Individual Number (DMR standard numbering scheme

FPP Fleet Partitioning Parameter - a parameter defined by the

FXO Foreign Exchange Office - the interface on a VoIP device for

GN Group Number (DMR standard numbering scheme term)

HA High Availability - critical elements can have a secondary unit

HTTP Hypertext Transfer (or Transport) Protocol - the data transfer

ILOM Integrated Lights Out Manager - provides advanced service

12 Preface Tait TN9300 DMR Tier 3 Trunked System Manual

INI Inter-Node Interface

INP Inter-Network Protocol (TN9500 terminology)

IP Ingress Protection - a guide to indicate the sealing on an

L0 The minimum signal level used attempting to acquire control

L2 A signal level at or above which offers optimum service. In

LDT The T1542 Line Dispatcher Terminal, a common example of

LIP Location Information Protocol

MAP27 Mobile Access Protocol for MPT 1327

MEP Miniaturization Extent Parameter - a parameter defined by the

MPT 1327 Industry standard for trunked radio communications networks

MS Mobile Subscriber - another term for radio user

MTBF Mean Time Between Failures

MTTR Mean Time To Repair

NAI Network Area Identity (DMR standard numbering scheme

NP Number Prefix (DMR standard numbering scheme term)

PABX Private Automated Branch Exchange

PDU Protocol Data Unit (i.e. a codeword)

Tait TN9300 DMR Tier 3 Trunked System Manual Preface 13

QoS Quality of Service - a term which denotes the expected