Capacity Max System Planner R2.9

System Release 2.
9
MOTOTRBO™ CAPACITY MAX
System Planner
APRIL 2018
*MN003523A01*
© 2018 Motorola Solutions, Inc. All rights reserved MN003523A01-AC
MN003523A01-AC
Copyrights
Copyrights
The Motorola Solutions products described in this document may include copyrighted Motorola
Solutions computer programs. Laws in the United States and other countries preserve for Motorola
Solutions certain exclusive rights for copyrighted computer programs. Accordingly, any copyrighted
Motorola Solutions computer programs contained in the Motorola Solutions products described in this
document may not be copied or reproduced in any manner without the express written permission of
Motorola Solutions.
© 2018 Motorola Solutions, Inc. All Rights Reserved
No part of this document may be reproduced, transmitted, stored in a retrieval system, or translated
into any language or computer language, in any form or by any means, without the prior written
permission of Motorola Solutions, Inc.
Furthermore, the purchase of Motorola Solutions products shall not be deemed to grant either directly
or by implication, estoppel or otherwise, any license under the copyrights, patents or patent
applications of Motorola Solutions, except for the normal non-exclusive, royalty-free license to use that
arises by operation of law in the sale of a product.
Disclaimer
Please note that certain features, facilities, and capabilities described in this document may not be
applicable to or licensed for use on a specific system, or may be dependent upon the characteristics of
a specific subscriber unit or configuration of certain parameters. Please refer to your Motorola
Solutions contact for further information.
Trademarks
MOTOROLA, MOTO, MOTOROLA SOLUTIONS, and the Stylized M Logo are trademarks or
registered trademarks of Motorola Trademark Holdings, LLC and are used under license. All other
trademarks are the property of their respective owners.
European Union (EU) Waste of Electrical and Electronic Equipment (WEEE)

directive
The European Union's WEEE directive requires that products sold into EU countries must have
the crossed out trash bin label on the product (or the package in some cases).
As defined by the WEEE directive, this cross-out trash bin label means that customers and end-users
in EU countries should not dispose of electronic and electrical equipment or accessories in household
waste.
Customers or end-users in EU countries should contact their local equipment supplier representative or
service centre for information about the waste collection system in their country.
2
MN003523A01-AC
Contact Us
Contact Us
Motorola Solutions Support Center
The Solutions Support Center (SSC) is the primary contact for technical support included in your
organization's service agreement with Motorola Solutions.
Service agreement customers should be sure to call the SSC in all situations listed under Customer
Responsibilities in their agreement, such as:
• Before reloading software.
• To confirm troubleshooting results and analysis before taking action.
Your organization received support phone numbers and other contact information appropriate for your
geographic region and service agreement. Use that contact information for the most efficient response.
However, if needed, you can also find general support contact information on the Motorola Solutions
website, by following these steps:
• Enter motorolasolutions.com in your browser
• Ensure that your organization's country or region is displayed on the page. Clicking or tapping the
name of the region provides a way to change it.
• Select "Support" on the motorolasolutions.com page.
Comments
Send questions and comments regarding user documentation to
documentation@motorolasolutions.com.
Provide the following information when reporting a documentation error:
• The document title and part number
• The page number with the error
• A description of the error
3
MN003523A01-AC
Document History
Document History
Version Description Date
MN003523A01-AB Original release of the Capacity Max System Planner March 2016
manual.
MN003523A01-AB Second release of the Capacity Max System Planner November 2016
manual. This update includes the following changes:
• Radio Joining an Inactive Talkgroup Call
• Voice Site-Wide and Multi-Site All Call
• Data Applications
• Emergency Talkgroup
• Mechanisms to Restrict Radio Access to Capacity
Max System
• Radio Wi-Fi Support
• Radio Bluetooth Support
• Over the Air Battery Management
• Capacity Max Priority Monitor
• Capacity Max Talkgroup Affiliation List
• Capacity Max and WAVE5000
• Capacity Max Status Message
• Capacity Max Information Assurance
• Capacity Max Job Tickets
• Capacity Max Presence of a Radio User
• Application Deployment Options with MNIS Data
Gateways
• Active Talkpaths
• Ethernet Switch and IP Router Common Charac-
teristics
• Centralized Distribution of Packets
MN003523A01-AB Third release of the Capacity Max System Planner June 2017
• Capacity Max Job Tickets
- Job Ticket Registration
• Job Tickets Data Communication
• MNIS Network
• Verification Application Redundancy
• Capacity Max Over the Air Data Transport
- Data over Trunked Channels
4
MN003523A01-AC
Document History
Version Description Date
- Data over Control Channel

- Data over Revert Channel
- Data over Enhanced Revert Channel
- Confirmed Group Data
• Capacity Max Bridge
- Capabilities and Features of the Capacity Max
Bridge
- Call Types Supported by the Capacity Max
Bridge
- Call Types Not Supported by the Capacity Max
Bridge
MN003523A01-AC Fourth release of the Capacity Max System Planner April 2018
• Wi-Fi Security Support
• Certificate Management
- Feature Overview
- Certificate Enrollment
- Certificate Renewal and Rollover
- Design Consideration
• Reception of an Emergency Alarm or Call
- Emergency Alarm Indication
• Capacity Max Telephone Voice Calls
- Overview of Telephone Architecture and Sup-
ported Interface
• Channel Acquisition and Registration
• Service Request Queuing or Pre-empt an Ongoing
Call
• Allowing Request for Pre-emption
• Channel Allocation
- Late Entry to Voice Talkgroup Calls
• Dedicated Control Channel or Shared Channel
• Shared Control Channel
• Estimating Site Link Bandwidth Requirements
when SSC Router is Present in the System
• Application Deployment Options
5
MN003523A01-AC
Contents
Contents
Copyrights................................................................................................................... 2
Contact Us................................................................................................................... 3
Document History....................................................................................................... 4
List of Figures............................................................................................................14
List of Tables............................................................................................................. 16
About the Capacity Max System Planner............................................................... 17
What is Covered in This Manual..................................................................................................17
Helpful Background Information.................................................................................................. 17
Related Information..................................................................................................................... 17
Chapter 1: System Description................................................................................19
1.1 Capacity Max System Overview............................................................................................ 19
1.1.1 Trunking Methods of DMR....................................................................................... 19
1.1.2 Modes of Operation................................................................................................. 20
1.2 Capacity Max Control Channel.............................................................................................. 21
1.2.1 Dedicated Control Channel or Shared Control Channel.......................................... 21
1.2.2 Active Control Channel............................................................................................ 21
1.2.3 Multiple Control Channels........................................................................................22
1.2.4 Preferred Control Channel....................................................................................... 22
1.2.5 Shared Control Channel.......................................................................................... 22
1.2.6 Control Channel Rotation.........................................................................................23
1.3 Capacity Max Voice and Data Services Over Trunked Channels......................................... 24
1.3.1 Channel Acquisition and Registration...................................................................... 24
1.3.2 Initiation of Request for Services............................................................................. 24
1.3.3 Qualification of Service Requests............................................................................ 25
1.3.4 Service Setup Using All Start...................................................................................25
1.3.5 Service Request Queuing or Pre-empt an Ongoing Call......................................... 26
1.3.6 Allowing Request for Pre-emption........................................................................... 27
1.3.7 Channel Allocation................................................................................................... 27
1.3.8 Call Termination.......................................................................................................29
1.4 Capacity Max Voice Talkgroup Call.......................................................................................29
1.4.1 List of Valid Sites..................................................................................................... 29
1.4.2 List of Static Sites.................................................................................................... 30
1.4.3 Sites with Successful Affiliation................................................................................30
1.4.4 Talkgroup Call Affiliation.......................................................................................... 30
1.4.5 Broadcast Talkgroup Call Configuration.................................................................. 30
6
MN003523A01-AC
Contents
1.4.6 Radio Joining an Active Talkgroup Call................................................................... 31

1.5 Capacity Max Individual Voice Call........................................................................................31
1.5.1 Individual Call Types................................................................................................31
1.5.2 Individual Call Control.............................................................................................. 32
1.5.3 Individual Call Initiation............................................................................................ 32
1.6 Capacity Max Voice All Call...................................................................................................33
1.6.1 Voice Site-Wide, Multi-Site, and System Wide All Call............................................ 33
1.6.2 Control of All Call Capability for a Radio..................................................................33
1.6.3 Late Join Capability..................................................................................................34
1.6.4 Limit to Active All Calls at a Site.............................................................................. 34
1.7 Capacity Max Telephone Voice Calls.................................................................................... 34
1.7.1 Telephone Voice Call Types.................................................................................... 35
1.7.2 Methods of Dialing................................................................................................... 35
1.7.3 Telephone Call Answering....................................................................................... 35
1.7.4 Telephone Call Handling..........................................................................................35
1.7.5 Overdial....................................................................................................................36
1.7.6 Telephone Call Ending.............................................................................................36
1.7.7 Radio Telephone Capability Control........................................................................ 36
1.7.8 Radio User Call Type Permissions Control..............................................................36
1.8 Capacity Max MNIS Voice and Radio Command (VRC) Gateway........................................37
1.8.1 Gateways Architecture.............................................................................................37
1.8.2 Call Flow.................................................................................................................. 38
1.8.3 Voice Packet Replication......................................................................................... 38
1.9 Capacity Max MNIS Data Gateway....................................................................................... 39
1.9.1 Data Applications..................................................................................................... 39
1.10 Capacity Max Data Revert Channel.................................................................................... 40
1.10.1 Enhanced GPS Revert Channel for IP Data.......................................................... 40
1.10.2 Enhanced GPS Revert Channel for High Efficiency.............................................. 40
1.11 Capacity Max Location Services..........................................................................................41
1.11.1 Global Navigation Satellite System (GNSS).......................................................... 42
1.11.2 GNSS Services for Radio Users............................................................................ 43
1.11.3 Services Provided to a Location Application..........................................................44
1.11.4 Location Data Channel Types................................................................................45
1.12 Capacity Max Remote Monitoring .......................................................................................45
1.12.1 Radio Configuration............................................................................................... 45
1.12.2 System Server Configuration................................................................................. 45
1.12.3 Remote Monitor Duration Recommendation..........................................................46
1.13 Capacity Max Radio Check................................................................................................. 46
1.14 Capacity Max Call Alert....................................................................................................... 47
7
MN003523A01-AC
Contents
1.14.1 Call Alert Feature Description................................................................................ 47

1.15 Capacity Max Emergency Handling (Alarm and Call)..........................................................47
1.15.1 Emergency Initiation.............................................................................................. 48
1.15.2 Alarm Type.............................................................................................................48
1.15.3 Emergency Search Tone....................................................................................... 49
1.15.4 Emergency Talkgroup............................................................................................49
1.15.5 Reception of an Emergency Alarm or Call.............................................................49
1.15.6 Transmission of Location Information During an Emergency................................ 50
1.15.7 Feature Interaction During an Emergency............................................................. 50
1.15.8 Prioritization of Emergencies................................................................................. 50
1.15.9 Emergency Mode...................................................................................................51
1.15.10 Interaction Between Voice to Follow and Location on Emergency...................... 52
1.15.11 Hot Microphone Cycles........................................................................................52
1.16 Capacity Max Multi-Site Roaming........................................................................................52
1.16.1 Multi-Site Network..................................................................................................53
1.16.2 Site Neighborhood................................................................................................. 53
1.16.3 Received Signal Sampling..................................................................................... 53
1.16.4 Roaming.................................................................................................................54
1.16.5 Site Hunting........................................................................................................... 54
1.16.6 Control Channel Qualification................................................................................ 55
1.16.7 Failure Handling.....................................................................................................55
1.16.8 Call Handover........................................................................................................ 55
1.16.9 Manual Site Roam................................................................................................. 56
1.16.10 Site Locked or Unlocked...................................................................................... 56
1.17 Capacity Max Radio Registration and Presence Notifier.....................................................56
1.17.1 Connection of Third-Party Applications to Presence Notifier................................. 57
1.17.2 Presence, Absence, and Mobility Information........................................................57
1.17.3 Subscription and Notification................................................................................. 58
1.17.4 Configuration Parameters for Presence Notifier.................................................... 59
1.17.5 Presence Notifier Redundancy.............................................................................. 59
1.18 Radio Access Restriction in Capacity Max System............................................................. 59
1.18.1 Mechanisms to Restrict Radio Access to Capacity Max System...........................59
1.18.1.1 Authentication.......................................................................................... 60
1.18.1.2 Subscriber Access Control.......................................................................62
1.18.1.3 Stun/Revive..............................................................................................62
1.18.1.4 Kill............................................................................................................ 63
1.19 Capacity Max System Advisor............................................................................................. 63
1.19.1 System View.......................................................................................................... 64
1.19.2 Real Time Call Monitoring......................................................................................64
8
MN003523A01-AC
Contents
1.19.3 North Bound Interface............................................................................................65

1.19.4 Discovery and Network Database..........................................................................65
1.19.5 Device Synchronization......................................................................................... 66
1.19.6 Communication Link Management........................................................................ 66
1.19.7 Command Operation .............................................................................................66
1.19.8 Network Events......................................................................................................66
1.19.9 Alarms....................................................................................................................67
1.20 Capacity Max Radio Management.......................................................................................67
1.20.1 Advantages of Radio Management........................................................................68
1.20.2 Radio Management Programming Options............................................................69
1.21 Radio Wi-Fi Support............................................................................................................ 70
1.21.1 Wi-Fi Network Name (SSID).................................................................................. 70
1.21.2 Wi-Fi Security Support........................................................................................... 70
1.21.3 Wi-Fi Default Profile............................................................................................... 71
1.21.4 Wi-Fi Channel Usage.............................................................................................71
1.21.5 Wi-Fi Network Settings.......................................................................................... 71
1.21.6 Wi-Fi Network Protocols........................................................................................ 72
1.21.7 Radio Management................................................................................................72
1.21.8 Recommended First Time Work Flow....................................................................73
1.22 Certificate Management.......................................................................................................73
1.22.1 Certificate Management Feature Overview........................................................... 73
1.22.2 Certificate Enrollment.............................................................................................74
1.22.3 Certificate Renewal and Rollover...........................................................................74
1.22.4 Design Considerations...........................................................................................75
1.23 Radio Bluetooth Support......................................................................................................75
1.23.1 Bluetooth Pairing and Connection......................................................................... 75
1.23.2 Bluetooth Headset/PTT and Radio Operation....................................................... 76
1.23.3 Bluetooth Barcode Scanner Operation.................................................................. 77
1.23.4 Bluetooth Personal Area Networking (PAN) Operation......................................... 77
1.23.5 Recommended Bluetooth Devices.........................................................................77
1.23.6 Avoiding Accidental Connection............................................................................ 78
1.24 Over The Air Battery Management ..................................................................................... 78
1.24.1 Over The Air Battery Management Overview........................................................ 78
1.24.2 Over The Air Battery Management Theory of Operations..................................... 79
1.25 Capacity Max Priority Monitor..............................................................................................79
1.25.1 Priority Monitor Feature Description...................................................................... 79
1.25.2 Configuration in the Capacity Max System Server (CMSS)...................................80
1.25.3 Configuration in the Capacity Max Radio...............................................................80
1.26 Capacity Max Talkgroup Affiliation List................................................................................80
9
MN003523A01-AC
Contents
1.26.1 Affiliation List Configuration in the Capacity Max Radio........................................ 81

1.26.2 Loading Impacts of Talkgroup Affiliation List......................................................... 81
1.27 Capacity Max and WAVE5000............................................................................................ 81
1.27.1 Capacity Max and WAVE5000 Overview...............................................................81
1.27.2 Supported Capacity Max Features........................................................................ 82
1.27.3 Connection into Capacity Max System.................................................................. 82
1.28 Capacity Max Status Message............................................................................................ 82
1.28.1 Status Message Feature Description.....................................................................82
1.28.2 Configuration in the Capacity Max System Server................................................ 83
1.28.4 Status List and Status Message Initiation.............................................................. 83
1.29 Capacity Max RX Group List and Scan............................................................................... 83
1.29.1 RX Group List Description..................................................................................... 84
1.29.2 Front Panel Scan List.............................................................................................84
1.30 Voice and Data Privacy in Capacity Max.............................................................................85
1.30.1 Types of Privacy.................................................................................................... 85
1.30.2 Strength of the Protection Mechanism...................................................................86
1.30.3 Scope of Protection................................................................................................86
1.30.4 Effects on Performance......................................................................................... 87
1.30.5 Privacy Configuration.............................................................................................87
1.31 Capacity Max Information Assurance.................................................................................. 87
1.31.1 Over The Air IA Confidentiality, Integrity and Authentication................................. 88
1.31.2 IP Network IA Confidentiality, Integrity and Authentication....................................88
1.31.3 System Configuration and Radio Database Confidentiality and Authentication.... 88
1.31.4 Information Assurance (IA) Availability.................................................................. 89
1.31.5 IA Non-Repudiation................................................................................................90
1.32 Capacity Max Job Tickets....................................................................................................90
1.32.1 Job Ticket Registration.......................................................................................... 91
1.32.2 Job Ticket Configuration........................................................................................ 91
1.32.3 Job Tickets Inbox Folders...................................................................................... 91
1.32.4 Radio Created Job Tickets.....................................................................................92
1.32.5 Delete All Job Tickets............................................................................................ 92
1.32.6 Presence of a Radio/User in Capacity Max........................................................... 92
1.32.7 Job Tickets Data Communication.......................................................................... 92
1.32.8 MNIS Networks...................................................................................................... 92
1.33 Capacity Max Presence of a Radio User.............................................................................93
1.33.1 User ID...................................................................................................................93
1.33.2 User Interface........................................................................................................ 93
10
MN003523A01-AC
Contents
1.33.3 Verification of Users Name.................................................................................... 94

1.33.4 Verification Application Redundancy..................................................................... 94
1.34 Capacity Max Architecture and Configurations....................................................................95
1.34.1 Communication Network........................................................................................96
1.34.2 Sites....................................................................................................................... 97
1.34.3 Gateways............................................................................................................... 97
1.34.4 Servers...................................................................................................................98
1.34.5 Deployment of Topologies..................................................................................... 98
1.35 Capacity Max Over-the-Air Data Transport....................................................................... 102
1.35.1 Data over Trunked Channels............................................................................... 102
1.35.2 Data over Control Channel.................................................................................. 103
1.35.3 Data over Revert Channel................................................................................... 103
1.35.4 Data over Enhanced Revert Channel.................................................................. 104
1.35.5 Confirmed Group Data.........................................................................................104
1.36 Capacity Max Bridge..........................................................................................................105
1.36.1 Capabilities and Features of the Capacity Max Bridge........................................ 105
1.36.2 Call Types Supported by the Capacity Max Bridge............................................. 106
1.36.3 Call Types Not Supported by the Capacity Max Bridge.......................................106
Chapter 2: System Planning.................................................................................. 107
2.1 Capacity Max System Planning........................................................................................... 107
2.1.1 High Level System Planning.................................................................................. 108
2.2 Capacity Max Hardware Specifications............................................................................... 115
2.2.1 Capacity Max System Server (CMSS) Hardware Specifications........................... 115
2.2.2 Repeater Hardware Specifications........................................................................ 116
2.2.3 Hardware Specifications for Recommended IP Network Equipment.....................118
2.2.4 Computer Specifications of Application................................................................. 119
2.2.4.1 Radio Management Computer Specifications..........................................120
2.2.4.2 Battery Management Computer Specifications........................................121
2.2.4.3 MNIS Data Gateway Computer Specifications........................................ 121
2.2.4.4 System Advisor Client Computer Specifications...................................... 122
2.2.4.5 ESU Client Computer Specifications........................................................122
2.3 Number of Users and Usage Prediction.............................................................................. 122
2.3.1 Active Radio Users in the System Simultaneously................................................ 123
2.3.2 Radio User’s Call Rate and Call Duration Prediction.............................................124
2.3.3 Average Number of Sites in a Call Prediction........................................................126
2.3.4 Voice Console Call Rate and Call Duration Prediction.......................................... 130
2.3.5 Outbound Data Application Transmissions per Hour Prediction............................130
2.3.6 Inbound Periodic Location Transmissions per User.............................................. 130
2.4 Transmission, Message and Quasi Transmission Trunking................................................ 131
11
MN003523A01-AC
Contents
2.4.1 Trunking Type Effects............................................................................................ 131

2.5 Number of Trunking Repeaters Selection in Capacity Max................................................. 132
2.5.1 Strategy Types.......................................................................................................132
2.5.2 Number of Users and their Usage Prediction........................................................ 135
2.5.3 Number of Trunking Repeaters Calculation...........................................................135
2.5.4 Grade of Service.................................................................................................... 137
2.5.5 Number of Required Trunking Repeaters.............................................................. 138
2.5.6 System Limitations.................................................................................................138
2.6 Number of Data Revert Repeaters Selection...................................................................... 140
2.6.1 Enhanced GPS (EGPS) Revert Channel with IP Data.......................................... 140
2.6.2 Enhanced GPS (EGPS) Revert Channel with High Efficiency Data...................... 141
2.7 Application Deployment Options with MNIS Data Gateways...............................................141
2.7.1 Application Deployment Options............................................................................141
2.8 Number of VRC Gateways and Talkpaths Selection........................................................... 145
2.8.1 VRC Gateway Capacity......................................................................................... 146
2.8.2 Active Talkpaths.....................................................................................................146
2.8.3 Additional Notes on Talkpath Estimations............................................................. 148
2.8.4 Talkpath Licenses and VRC Gateway................................................................... 149
2.9 Network Components for Capacity Max IP Connectivity..................................................... 149
2.9.1 Physical Location Requirements............................................................................149
2.9.2 Ethernet Switch and IP Router Common Characteristics...................................... 150
2.9.3 Ethernet Switch Characteristics............................................................................. 151
2.9.4 IP Router Characteristics....................................................................................... 151
2.9.5 WAN Links (Site Links).......................................................................................... 152
2.10 IP Bandwidth Per Site Requirement for Capacity Max...................................................... 153
2.10.1 Factors Influencing the Required Bandwidth Amount on a Site Link................... 153
2.10.2 Tunneling Modes................................................................................................. 155
2.10.3 Link Requirements............................................................................................... 156
2.10.3.1 Delay/Latency........................................................................................ 156
2.10.3.2 Jitter....................................................................................................... 157
2.10.3.3 Packet Loss............................................................................................158
2.10.4 Site Link Bandwidth Requirements for Repeater Traffic...................................... 158
2.10.5 GRE Tunneling, Uplink Bandwidth Requirement................................................. 159
2.10.6 GRE Tunneling, Downlink Bandwidth Requirement............................................ 163
2.10.7 Bandwidth Requirements Estimation and Examples........................................... 163
2.10.8 Centralized Distribution of Packets...................................................................... 171
2.10.9 Tunneling Impact on Link Bandwidth Requirements............................................172
2.11 Frequencies Acquired from Frequency Coordinator..........................................................174
2.11.1 Acquisition of New Frequencies (Region Specific).............................................. 174
12
MN003523A01-AC
Contents
2.11.2 Conversion of Existing Licenses (Region Specific)..............................................175

2.11.3 Digital Emission Designator................................................................................. 176
2.11.4 Station Class and Radio Service Codes.............................................................. 176
13
MN003523A01-AC
List of Figures
List of Figures
Figure 1: Recommended First Time Work Flow..................................................................................... 73
Figure 2: Certificate Enrollment.............................................................................................................. 74
Figure 3: Certificate Renewal and Rollover............................................................................................ 74
Figure 4: Registration Communication System Topology...................................................................... 91
Figure 5: Capacity Max System Configuration....................................................................................... 96
Figure 6: Two RF sites are co-located in Capacity Max System Topology............................................ 99
Figure 7: Core Site is co-located with a RF Site in Capacity Max System Topology............................. 99
Figure 8: Core and Management Sites are co-located with a RF Site in Capacity Max System
Topology..........................................................................................................................................100
Figure 9: Single Site Capacity Max System Topology..........................................................................100
Figure 10: RF, Core and Application Sites at Customer Network in Capacity Max System Topology. 101
Figure 11: RF, Core, Management and Applications Sites at Customer Network in Capacity Max
System Topology.............................................................................................................................102
Figure 12: A Typical Capacity Max System..........................................................................................108
Figure 13: System Design Tool User Interface for Capacity Max.........................................................109
Figure 14: Number of RF Sites (1-20) vs. Historical Sites per Group Call........................................... 127
Figure 15: Number of RF Sites (20-250) vs. Historical Sites per Group Call....................................... 128
Figure 16: Number of Repeaters Versus Active Users in Simple Strategy.......................................... 133
Figure 17: Number of Repeaters Versus Active Users in Better Strategy............................................134
Figure 18: The Inputs and Outputs of Interest for a Site...................................................................... 134
Figure 19: Number of Required Repeaters Versus Call Rate versus Call Duration............................. 138
Figure 20: Deployment of Data Applications on Separate Computers................................................. 142
Figure 21: Link Bandwidth Requirement Per Site.................................................................................153
Figure 22: No GPS (15 Sites)...............................................................................................................159
Figure 23: No GPS (250) Sites.............................................................................................................160
Figure 24: Enhanced GPS Revert Channel for IP Data (15 sites)........................................................160
Figure 25: Enhanced GPS Revert Channel for IP Data (250 Sites)..................................................... 161
Figure 26: Enhanced GPS Revert Channel for High Efficiency Data (15 sites)................................... 161
Figure 27: Enhanced GPS Revert Channel for High Efficiency Data (250 sites)................................. 162
Figure 28: Number of Revert Repeaters versus Number of Trunked Repeaters at Site...................... 162
Figure 29: Downlink Bandwidth for Site with Call Monitoring Application.............................................164
Figure 32: Downlink Bandwidth at Site with Trunked Controller...........................................................166
Figure 33: Uplink Bandwidth at Site with Trunked Controller............................................................... 167
Figure 34: Uplink Bandwidth at Site with Trunked Controller............................................................... 168
Figure 35: Downlink Bandwidth at Site with VRC Gateway(s)............................................................. 169
14
MN003523A01-AC
List of Figures
Figure 36: Uplink Bandwidth at Site with VRC Gateway(s).................................................................. 169

Figure 37: Uplink Bandwidth Requirements for a Four Repeater Site..................................................173
Figure 38: Uplink Bandwidth Requirements for an Eight Repeater Site...............................................173
15
MN003523A01-AC
List of Tables
List of Tables
Table 1: Trunking Methods and the Call Hang Time.............................................................................. 19
Table 2: Number of Updates per Minute per Channel (Slot).................................................................. 40
Table 3: Number of Updates per Minute per Channel (Slot).................................................................. 41
Table 4: GNSS Performance Specifications for GPS.............................................................................42
Table 5: Subscribed Events....................................................................................................................58
Table 6: Configurable Parameters for Presence Notifier........................................................................59
Table 7: Radio Services......................................................................................................................... 62
Table 8: Wi-Fi Default Profile..................................................................................................................71
Table 9: COTS Bluetooth Devices Recommended by Motorola Solutions.............................................77
Table 10: Summary for CMSS Hardware Specifications......................................................................115
Table 11: Hardware Specifications for MTR3000*............................................................................... 116
Table 12: Hardware Specifications for XPR8400*................................................................................116
Table 13: Hardware Specifications for XPR8380*................................................................................117
Table 14: Hardware Specifications for SLR5700*................................................................................ 117
Table 15: Hardware Specifications for HP MSR2003 AC Router.........................................................118
Table 16: Hardware Specifications for Cisco 2911 Router...................................................................118
Table 17: Hardware Specifications for HP Procurve 2530-24 Switch.................................................. 119
Table 18: Hardware Specifications for Cisco 3650 Switch................................................................... 119
Table 19: Recommendations for Radio Management Computer Specifications.................................. 120
Table 20: Recommendations for Battery Management Computer Specifications................................ 121
Table 21: Recommendations for MNIS Data Gateway Computer Specifications.................................121
Table 22: Recommendations for System Advisor Client Computer Specifications.............................. 122
Table 23: Recommendations for ESU Client Computer Specifications................................................122
Table 24: The Number of Updates per Minute per Site........................................................................140
Table 25: The Number of Updates per Minute per Site........................................................................141
Table 26: Guidelines for Application Deployment with the MNIS Data Gateway................................. 144
Table 27: VRC Gateway Capacity........................................................................................................146
Table 28: Talkpaths Required for each Call Type................................................................................ 148
Table 29: Ethernet Switch and IP Router Common Characteristics.....................................................150
Table 30: Ethernet Switch Characteristics............................................................................................151
Table 31: IP Router Characteristics......................................................................................................151
Table 32: Capabilities and Link Bandwidth Requirements of Tunneling Modes...................................155
Table 33: The Downlink Bandwidth Required for a Site....................................................................... 163
16
MN003523A01-AC
About the Capacity Max System Planner
About the Capacity Max System

Planner
The system planner is designed to provide information concerning the impact of the Capacity Max
features on pre-sales system planning considerations.
What is Covered in This Manual

This guide contains the following chapters:
• System Description on page 19
• System Planning on page 107
Helpful Background Information

Motorola Solutions offers various courses designed to assist in learning about the system. For
information, go to http://www.motorolasolutions.com/training to view the current course offerings and
technology paths.
Related Information
Motorola Solutions offers various courses designed to assist in learning about the system. For
information, go to http://www.motorolasolutions.com/training to view the current course offerings and
technology paths.
Related Information Purpose

Capacity Max Installation and Con- Provides installation and configuration content to sup-
figuration Manual port a MOTOTRBO™ Capacity Max system.
Capacity Max System Operations, Provides basic operations, troubleshooting, and mainte-
Troubleshooting, and Maintenance nance content to support a MOTOTRBO™ Capacity Max
Guide system.
Capacity Max System Release Up- Provides instructions for upgrading software in a MO-
grade Guide TOTRBO™ Capacity Max system from one system re-
lease to the next system release.
Capacity Max Migration Guide Provides instructions for using the Capacity Max Bridge
to migrate from the MOTOTRBO™ Connect Plus
trunked radio system to the Capacity Max commercial
grade trunking system.
Capacity Max System Advisor Guide Provides fault management, system, and call monitoring
solutions for a Capacity Max system.
MOTOTRBO CPS and AirTracer Ap- Provides the installation procedures and system re-
plications Installation Guide quirements for following applications:
• MOTOTRBO™ Customer Programming Software
• Radio Management Server and Radio Management
Device Programmer
• MOTOTRBO™ AirTracer
17
MN003523A01-AC
About the Capacity Max System Planner
Related Information Purpose
• MOTOTRBO™ RDAC
• MOTOTRBO™ Tuner
Repeater Diagnostics and Control Explains the features of the MOTOTRBO™ RDAC,
(RDAC) User Guide and Online Help which is a standalone Windows application for system
technicians who need to run diagnostics on the radio
(repeater or base radio) that has the RDAC capability.
MOTOTRBO CPS Radio Manage- Provides information about the Customer Programming
ment User Guide and Online Help Software structure and features which allows techni-
cians to manage all radio components, in addition with
Radio Management which provides a centralized man-
agement of programming radios in-the-field.
MOTOTRBO Radio Management Provides information about the Radio Management
User Guide and Online Help (RM) which allows the user to manage an entire fleet of
radios that are connected to the Radio Management
Configuration Client (RMC).
MOTOTRBO System Design Tools Estimates the infrastructure and loading constraints on
a MOTOTRBO™ system. The System Design Tools is a
down-loadable program from Motorola Online.
WAVE 5000 Solution System Plan- Provides guidance on when it is appropriate for a
ner for release 5.13 WAVE 5000™ deployment with a MOTOTRBO™ system.
Wave 7000 System Planner for re- Provides system operators' supporting the WAVE
lease 17.3 7000™ server to collect and generate reports on statisti-
cal data on the MOTOTRBO™ system performance.
SmartPTT PLUS Provides an explanation of the components of 3rd party
supported solution for Control Rooms compatible with
MOTOTRBO™ systems.
IMPRES Over Air Battery Manage- Provides information about the functionality of the appli-
ment cation managing batteries for radio fleets.
Radio Management Deployment Provides recommendations for deploying an RM system
Guide within a customer's network. It provides hardware rec-
ommendations for the various RM components based
on customer requirements and the number of radios in
the fleet. This guide is included with the RM Installation
Suite DVD media.
Standards and Guidelines for Com- Provides standards and guidelines that should be fol-
munication Sites Feature Guide lowed when setting up a communications site. Also
known as the R56 manual.
Radio Management System Planner Provides information about Radio Management system
components, installation, and troubleshooting of possi-
ble issues.
18
MN003523A01-AC
System Description
Chapter 1
System Description
This section describes the Capacity Max System features.
1.1
Capacity Max System Overview
This section describes a Capacity Max system.
Capacity Max is a trunked radio system based on MOTOTRBO control channels. MOTOTRBO digital
radio products are marketed by Motorola Solutions primarily to business and industrial users.
MOTOTRBO uses the European Telecommunications Standards Institute (ETSI) Digital Mobile Radio
(DMR) standard, that is, two-slot Time Division Multiple Access (TDMA), to pack simultaneous voice or
data in a 12.5 kHz channel (6.25 kHz equivalent).
MOTOTRBO offers multiple radio systems, which are IP Site Connect, Capacity Plus, Connect Plus,
and Capacity Max. All MOTOTRBO radio systems are trunked systems, except for IP Site Connect,
which is a conventional multisite system. A trunked system allows the radios to share the channels. It
allows a large number of talk groups to communicate over few channels and effectively increases the
utilization of channels.
The trunking in Capacity Plus uses the rest channel instead of the control channel. In a control channel
based system, the idle radios wait on the current control channel, but in a rest channel based system,
a call starts at the rest channel, and the non-participating radios move to the next rest channel.
Connect Plus and Capacity Max are control channel based system. The main difference between them
is that Capacity Max is based on the ETSI DMR trunking protocol, while Connect Plus follows a
proprietary trunking protocol.
1.1.1
Trunking Methods of DMR
Capacity Max supports all the trunking methods of DMR. It supports "transmission trunking", "quasi-
transmission trunking", and "message trunking". There are no explicit configurations for these trunking
methods. They are achieved by configuring suitable values for the Call Hang Time. Table 1 explains
the trunking methods and its Call Hang Time.
Table 1: Trunking Methods and the Call Hang Time

Trunking Definition Advantages and Disadvantag- Configuration
Methods es
Transmis- A trunked channel is allo- Users experience a delay for Call Hang
sion cated on start of every each transmission particularly Time = 0
transmission of a call. At when the system is busy, when
the end of a transmission no trunked channel is available.
(for example, release of the The call processing capacity of a
PTT), the trunked channel site is less (Control channel is
is de-allocated and all the used for starting every transmis-
participating radios return sion). The trunked channel uti-
to the control channel. The lization is high, as trunked chan-
next transmission is allo- nels are allocated only during
transmissions.
19
MN003523A01-AC
Chapter 1: System Description
cated a new trunked chan-

nel.
Quasi-trans- A trunked channel is allo- This method overcomes the de- Suggested
mission cated for the duration of lay of Transmission trunking ex- Call Hang
the call. At the end of a cept for the first transmission. Time = 2 to 6
transmission (for example , The call processing capacity of a seconds
release of the PTT), the site is good. Control channel is
channel remains allocated used for starting only the first
for a short Call Hang Time transmission. The trunked chan-
to permit the radio users to nel utilization is less (Trunked
speak. If the Call Hang channels are allocated also dur-
Time expires, the trunked ing Call Hang Times).
channel is de-allocated and
the call ends.
Message A trunked channel is allo- The delay in starting of a trans- Suggested
cated for the duration of mission and call processing ca- Call Hang
the call. The trunked chan- pacity are same as that of Quasi- Time = 20 to
nel is de-allocated when transmission. The disadvantage 30 seconds
the call is explicitly cleared is that the channel remains allo-
by the call initiator (during cated even when there is signifi-
a talkgroup call), by either cant time gaps between the
party hanging up (during transmissions. This results in
an individual call), or on ex- less efficient use of the trunked
piry of a large Call Hang channels.
Time.
1.1.2
Modes of Operation
Capacity Max increases the capacity (for example, the number of calls per unit of time) of a radio
system beyond what is supported by the DMR trunking protocol. To achieve this, the Capacity Max
infrastructure offers the following two modes:
1 Open System Mode — This mode uses DMR trunking protocol and therefore it supports both
MOTOTRBO and non-MOTOTRBO radios. In this mode, a Capacity Max system provides more
capacity when it is working with the MOTOTRBO radios. Some of the methods used for capacity
enhancements are:
• Registration on second slot: A MOTOTRBO radio uses the second slot of the control channel for
registration and authentication, if the second slot of the control channel is not in a call. A
Capacity Max system allocates a call to the second slot of the control channel only if no idle
channels are available. This frees both inbound and outbound of the control channel for initiation
of other services.
NOTICE: The control channel of a Capacity Max system is always on the first slot.
• Arbitration during a call: During a call hang time, radios at different sites may try to initiate their
transmission almost at the same time. The system needs to arbitrate among them. MOTOTRBO
radios on a Capacity Max system do the arbitration over the trunked channels. This frees the
control channel.
2 Advantage Mode — This mode provides more capacity than the Open System Mode. All the
capacity enhancements of Open System Mode with MOTOTRBO radios are also available in
Advantage Mode.
20
MN003523A01-AC
It achieves higher capacity by compressing the announcement of ongoing calls over the outbound of
the control channel.
NOTICE: The outbound control channel becomes the dominant factor in restricting the capacity,
when more and more calls are multi-site calls.
Advantage Mode uses proprietary protocol over the air and therefore it does not support non-
MOTOTRBO radios. Some of the features (for example, faster “late entry” to an ongoing call), which
use proprietary messages over the air are only available in this mode.
Other than Open System Mode and Advantage Mode, a Capacity Max radio has a third mode (Open
Radio Mode), which is used by the radio when it is working in a Non-Motorola Solutions DMR Tier III
system. In this Open Radio Mode, a radio does not use any proprietary features.
1.2
Capacity Max Control Channel
This section describes the control channel in a Capacity Max system.
Capacity Max control channel is based on the DMR trunking protocol. The DMR trunking protocol
requires at least one logical channel to be assigned as a control channel. The control channel has an
inbound communication path for transmissions from radios, known as the inbound control channel. A
radio randomly accesses the inbound control channel to request access to the system. The required
resources (for example, channels) are then allocated by the system. The system informs the radios of
the allocated resources over an outbound communication path, known as the outbound control
channel. All the radios that are not participating in a call listen to the outbound control channel. The
allocated resources are released and can be subsequently allocated to other requests. This method of
sharing channels is known as trunking, and the channels are referred to as trunked channels.
1.2.1
Dedicated Control Channel or Shared Control Channel
The Capacity Max system transmits continuously over a dedicated control channel. One dedicated
control channel can support many trunked channels. This mode of operation provides the highest
performance and throughput.
Independent users or agencies can share frequencies in a band. The national communication
administrations mandated the channel to de-key and yield use of the channel to the co-channel users
when not in use. You should access the channel asynchronously since co-operative sharing of channel
is not possible in most of the cases. In this mode, the shared channel remains inactive, the repeater is
de-keyed, and a radio or the system uses the shared channel politely.
Capacity Max system supports both dedicated and shared channel as a control channel.
NOTICE: The shared control channel reduces the maximum call capacity of a site and slows
down the roaming of a radio to the site.
Capacity Max system does not support composite control channel. In a composite control channel, the
control channel reverts to a trunked channel if no other trunked channels are available. A composite
control channel is useful for a site, where only few frequency pairs are available.
1.2.2
Active Control Channel
The DMR Trunking protocol allows a site to operate with one or two control channels. Two control
channels increases the capacity of the site, but requires the radios at the site to be sub-divided into two
partitions. This allows load sharing between the two control channels.
The load sharing is not effective for calls, which require participation of radios from both the partitions.
This is because the system must inform the allocated resources to radios on the outbound path of both
21
MN003523A01-AC
control channels. Thus, a Capacity Max system supports one control channel at each site. To increase
the capacity of its control channel, a Capacity Max system off-loads certain uses (for example,
Registration and Authentication, Arbitration during hang times) of control channels to trunked channels.
To reduce configuration, the control channel of a Capacity Max system is always on the first slot of a
physical channel.
1.2.3
Multiple Control Channels
Capacity Max allows up to four channels to be designated as the candidate control channels.
To offer radio services, a site should have at least one repeater that is a candidate control channel.
Multiple candidate control channels help, when the active control channel fails. In the event of the
active control channel failure, one of the remaining candidate control channels is selected as the next
control channel.
1.2.4
Preferred Control Channel
Capacity Max allows one or more candidate control channel to be the “Preferred Control Channel”.
A non-preferred candidate control channel acts as a control channel, only if the site has no “Preferred”
candidate control channel. The preferred channel having the lowest “Repeater Id” is selected as the
control channel, when there are multiple preferred control channels.
The “Preferred” option is useful, when a frequency pair is more suitable (for example, less interference)
as the control channel over other candidate control channels.
1.2.5
Shared Control Channel
The Radio Management allows setting the candidate control channel attribute to "dedicated" and
"shared". The default attribute is the dedicated control channel.
The following combinations of the two attributes are allowed:
• preferred and dedicated
• preferred and shared
• non-preferred and dedicated
• non-preferred and shared
The candidate control channels at a site may be a mix of dedicated and shared channels.
The shared control channel repeater goes to sleep, that is no transmission over the air when the
following scenarios happen:
• The second slot is idle without call or registration of radio or user is in progress over the second
slot.
• The first slot has no activities such as grants, Acks, and announcements taking place.
During sleep, the shared control channel repeater monitors for interference (both inbound and
outbound). The shared control channel repeater makes itself ‘unavailable’ when interference happens.
This triggers selection of another candidate control channel if available as the next control channel. If
the selected control channel is engaged in a call, the on-going call is terminated including Emergency
and All Call. The occurrence of such call dropping is because there is on-going interference on the
control channel and the system is heavily loaded.
1 Note : It is suggested to detect outbound interference by having a mobile radio (one for each
shared control channel) connected to the repeater through GPIO line
22
MN003523A01-AC
The probability of dropping a call can be reduced by configuring the repeaters:

• There are no “Preferred” candidate control channels.
• The IDs of repeaters having candidate control channels are lower than the IDs of the trunked
repeaters.
NOTICE: The candidate control channel of lowest ID is selected as the next control channel.
• The “Preference Level” of candidate control channels repeaters are lower, that is of a numerically
higher value than the “Preference Level” of the trunked repeaters.
• The “Preference Level” of a candidate control channel repeater with lower ID is lower than the
“Preference Level” of a candidate control channel repeater with higher ID.
For example, refer to the following table:
Role Candidate Candidate Candidate Candidate Trunked Trunked

CC CC CC CC
Repeater 1 2 3 4 5 6
ID
Preference 5 (Least) 4 3 2 1 (Most) 1 (Most)
Level
During sleep, the shared control channel repeater periodically wakes up and transmits beacons, which
helps a radio in roaming to the site and also staying on the site during sleep. The beacon interval is a
system-wide parameter and is configurable from 1 - 10 seconds. The beacon duration is fixed at 240
ms. A lower beacon interval reduces time to roam but it also reduces the sharing of the channel.
The existing periodic verification applies on the candidate control channels when the active control
channel is in site trunking mode. When a radio finds a shared candidate control channel in the system
trunking mode, it starts using this shared control channel as the active control channel. A sleeping
shared control channel transmits for a short duration (beacon). The radio takes a longer time, which is
approximately five minutes if the beacon interval is two seconds to find the shared control channel.
1.2.6
Control Channel Rotation
A MOTOTRBO repeater is capable of performing the role of a control channel continuously without
increasing its failure rate (for example, failure of power amplifier). Thus, the Capacity Max system does
not move the control channel periodically.
In a Capacity Max system, the control channel moves from repeater A to repeater B, only if:
• Repeater A fails and there is no hardware redundancy; or
• Both repeater A and its redundant repeater fail; or
• Repeater A is not the preferred control channel repeater, and repeater B which is the preferred
control channel repeater, powers on or has recovered from a failure.
NOTICE: The selection of a candidate control channel as the next control channel is
independent of the channel being "dedicated" or "shared".
23
MN003523A01-AC
1.3
Capacity Max Voice and Data Services Over Trunked Channels
This section describes calls initiated over the air on a control channel and describes the life cycle of a
call, including call initiation, call queuing, call grant or rejection, call transmissions, and call termination.
This section focuses on the parts of the life cycle that apply to multiple call types.
Overview
Call processing is the primary function of Capacity Max and any other radio system. A call is initiated
either over the air (that is, by a radio) or over the wire (that is, by a device such as a voice or data
gateway). In Capacity Max, a call is initiated over the air either on the control channel or on the revert
channels. This section describes only calls initiated over the air on a control channel. A Capacity Max
system supports multiple types of calls. This section focuses on the parts of the life cycle that apply to
multiple call types.
1.3.1
Channel Acquisition and Registration
Before initiating a service at a site, a radio must acquire the control channel of the site, and be
successfully registered at the site (except when the site is in Site Trunking mode).
A radio registers with the system:
• On power-on
• On roaming to a site, which is not in site-trunking mode
• On changing the personality (that is knob position), where the personality is one of the followings:
- The two personalities are from two different systems
- The two personalities have different TX members.
• When the radio has not received a response for its request within the number of hours configured
as the Inactivity Check time
• On change in the subscribed Talkgroups
Successful registration requires the following conditions:
• Subscriber Access Control (SAC) should have an entry for the radio.
• The radio should not be disabled in the SAC.
• The site should be in the list of the Valid Sites of the radio in the SAC.
• Authentication is required by the system with the following conditions:
- The radio has the right key.
- The SAC has the radio physical serial number (PSN) (For MOTOTRBO radio only).
• The radio is in the coverage area of the control channel of the site, that is, the radio is receiving the
outbound transmission over the control channel.
• The color code and the SYScode in the outbound transmission match those configured in the radio.
An unregistered radio does not unmute to a voice or data call.
1.3.2
Initiation of Request for Services
A radio initiates all requests for services over a control channel by randomly accessing the control
channel.
24
MN003523A01-AC
After acquiring a control channel and successfully registering, a radio that needs to initiate a service
accesses the control channel as specified in the random access procedure defined in the DMR III
standard. The main purpose of the random access procedure is to reduce collisions caused by
simultaneous accesses of the control channel by multiple radios. The random access procedure also
minimizes access delays and maximizes throughput under heavy traffic loads.
An attempt at random access may fail under any of the following conditions:
• The time slot, which was randomly selected by the radio for accessing the control channel, is no
longer available for random access. When the infrastructure solicits a response from a radio, it
transmits a packet data unit (PDU) on the outbound channel. In order to prevent a collision
occurring between this solicited response and a random access transmission by another radio, the
infrastructure prohibits any random access transmissions in the given timeslot.
• Another radio randomly accesses the same timeslot. Subject to the relative signal strength of the
transmissions, one or both transmissions may be lost over the air.
• The radio’s signal is corrupted by noise.
• The request from the radio is received over-the-air but is lost over the wireline network in the
infrastructure.
To reduce the probability of failure of random access, a Capacity Max radio makes multiple attempts
with random delays in between. The maximum number of attempts for requesting emergency services
is higher than the one for requesting non-emergency services. Due to multiple attempts and random
delay in between them, a random access may take a long time. Capacity Max puts an upper limit
(approximately ten seconds) on the duration of the random access procedure.
Radio users are not required to keep the push-to-talk (PTT) button pressed during the service request
process. Momentarily pressing the PTT button is sufficient.
1.3.3
Qualification of Service Requests
A Capacity Max system qualifies all requests for services.
On receipt of a service request from a radio, the infrastructure verifies the source and target (if any) of
the request. The source (that is, the requesting radio) must satisfy all of the following conditions:
• The requesting radio is present in the SAC.
• The requesting radio is enabled in the SAC.
• The requesting radio is registered.
• The requesting radio is permitted to be on its current site in the SAC.
• The requesting radio is permitted to initiate the requested service in the SAC.
The target and the conditions that the target must satisfy depend upon the type of the service and are
described in articles on specific call types.
1.3.4
Service Setup Using All Start
A Capacity Max system sets up a service using “All Start” method.
A Capacity Max system starts a qualified service request only when at least one trunked channel is
available at all the sites that are associated with the service at that time. This method may delay the
start of a service (when trunked channels are not available at one or more associated sites), but
guarantees that the all the associated sites participate in the service.
• For an individual call, the associated site(s) is/are the site(s) where the source and target radios are
present.
25
MN003523A01-AC
• For a talkgroup call, the associated site(s) consist of the following:

- The sites that a system administrator has statically associated with the talkgroup by configuring
in the radio management application.
- The sites where at least one radio has affiliated for the talkgroup.
- The site where the call request is being initiated.
The system checks the availability of channels only at the sites that are present in the system at that
time. When a site is isolated from the rest of the system, the system does not include the site in the
associated sites.
1.3.5
Service Request Queuing or Pre-empt an Ongoing Call
If a trunked channel is not available at one or more sites associated with a service request, one of the
following scenarios occurs:
• The service request is queued and the source radio is informed.
• In following cases, on-going calls are pre-empted and the channel is allocated to the service
request.
- Emergency Voice Call and All Call follows the “All Start” method. If a trunked channel is not
available at the associated site, a busy trunked channel (busy with anything besides an
Emergency or All call) is assigned to the call. The request is rejected if all the channels at the
site are busy with Emergency or All calls.
- A Capacity Max system allows a radio user to request for pre-emption if required for its service
request. For more details, see Allowing Request for Pre-emption on page 27.
When a trunked channel becomes available, the system checks the service requests in queue for the
availability of all the required channels. If there are more than one such service requests, then the
system selects one of them and allocates channels to the selected service request. The selection is
based on the priority of the service request, which is the maximum of the priority of the initiating radio,
and the priority of the target (a radio or a talkgroup).
A Capacity Max system allows the system owner to configure a priority for each radio and each
talkgroup.
Service requests having the same priority are processed using the first-come-first-served principle.
A service request waits in the queue until all required channels become available. This has the
following implications:
• Between two service requests having the same priority, the request with fewer required channels is
likely to be processed first.
• During heavy usage, requests remain in the queue longer, and the radio may receive the grant after
its waiting period is over. When this occurs, the service initiating radio does not initiate transmission,
and the allocated channels are wasted for few seconds. A system owner can configure the duration
of the wait period (that is, the TP_Timer) for which a radio waits for the grant of its queued request.
Radios in a heavily loaded system should be configured with a greater TP_Timer (a system-wide
parameter).
Some of the advantages of queuing in a loaded system are that it improves channel utilization, and a
radio user is not required to press PTT multiple times. A disadvantage is that in a heavily loaded
system, the recent requests have to wait for the older requests. Queing increases the delay in
processing a request. In many scenarios, the delay is not desirable. For this reason, a Capacity Max
system allows its system owner to disable or enable the queuing. When queuing is disabled, the
system does not use priority of radios or talkgroups, and the TP_Timer could be small (around 4
seconds).
26
MN003523A01-AC
When channels are assigned to a talkgroup request in the queue, all queued requests for the same
talkgroup and same call type (voice or data) are removed from the queue. A radio can have only one
service request in the queue at any time. When the radio makes a new service request, the previous
service request is removed from the queue.
1.3.6
Allowing Request for Pre-emption
A Capacity Max system allows a call initiator that is a radio user, the option board in the SU, a non-IP
peripheral connected to the SU, a dispatcher, or a data application to pre-empt an ongoing call in favor
of its next service request.
The system pre-empts only if there is no idle channel at the RF site.
A radio user can request for pre-emption using a programmable button that moves the selection in a
cyclic fashion between Normal and High. The change is applicable to user initiated call that is Voice
call, Text message over trunked channel, Job Ticket, but not location or telemetry. The selection resets
to its default value when the call ends.
The Radio Management allows user to set/reset a flag in the Subscriber Access Control (SAC) of a
radio including Voice application and Data Gateway. Only if the flag permits, the system allows the
request for pre-emption. The site allows the request for pre-emption from all radios during Site
Trunking and when SAC is unavailable.
The Radio Management allows user to set/reset a flag for each talkgroup. If the flag is set then a call to
a specified Talkgroup can pre-empt an ongoing call, if there is no idle channel at a RF site.
Call request is queued if there is no channel with lower priority calls than the call request. Out of all the
lower priority calls, the channels with the lowest priority calls are selected for pre-emption. The radio
which is transmitting over the air at the selected channel is forced to stop the transmission.
NOTICE:
Emergency and All Calls are never pre-empted.
Order of priority in descending order is Emergency Calls and All Calls, Pre-emption Calls,
Normal Calls.
1.3.7
Channel Allocation
A Capacity Max system allocates channels to a service request according to the system owner’s
preference.
A Capacity Max system allows system owners to configure their preferences for usage of a physical
trunked channel (both slots) in a repeater. The guidelines for assigning the preference level for a
trunked channel are:
• Exclusively licensed channels should have higher preference than the shared channels.
• Within shared channels, the preference is inversely proportional to the co-channel user activity.
When a service request is selected for allocation of channels, the system assigns a trunked channel at
a site according to the following rules.
• Within all ‘Idle’ trunked channels at that site, the high preference trunked channel is assigned before
the low preference trunked channel.
• Within same preference level, trunked channels are assigned in round robin method.
• The trunked channel on the second slot of a control channel repeater is assigned only when no
other idle channel is available at the site. The second slot of a control channel is used by MSI radios
for registration.
27
MN003523A01-AC
Retention of Ongoing Calls

Any changes in the system data do not affect the ongoing calls.
To set up a call, a Capacity Max system uses several data sets such as the Subscriber Access Control
(SAC) and static associations between sites and talkgroups. Any change in the data sets after the
allocation of channels to a call does not affect the call. For example, during a call, if the system owner
disables the source or destination of the call, the call does not stop.
Late Entry to Voice Talkgroup Calls

A radio can enter a voice talkgroup call if it was not on the control channel at the time of call initiation.
This condition may occur when the radio is at another site, out of coverage, in fade, transmitting over a
revert channel, or participating in another call.
A Capacity Max system supports late entry for voice talkgroup call only. The probability of having late
entry for an Individual call is small because an Individual call starts after acknowledgment from the
target radio/user.
To facilitate late entry, a site announces periodically all the ongoing voice talkgroup calls over the
control channel. The announcements are more frequent (that is, late entries are approx. 50% less late)
in Advantage mode than in Open System mode of a Capacity Max system. In Advantage mode, the
lateness can be further shortened by approximately 50%, if the talkgroups’ IDs are less than 1024.
Priority Monitor Feature

For radios participating in a call over trunked channels, ongoing Emergency Calls, All Calls, and calls
for priority talkgroups are announced periodically over the busy trunked channels. The announcements
are more frequent (that is, late entries are less late) if the emergency talkgroups IDs are less than
1024. On receiving an announcement, a radio moves to the announced call if the announced call is of
interest and has higher priority than its current call.
Floor Arbitration of Trunked Channels

A call is made of multiple transmissions, where the maximum time gap between two consecutive
transmissions is called call hang time. A Capacity Max system allows its system owner to configure
three hang times, one each for talkgroup voice call, individual voice call, and emergency voice call.
During a call, a radio accesses the trunked channel by being polite to its own color code (that is, a
radio cannot talk over other radios in a call) except in case of Voice Interrupt, and during a telephone
call a radio is impolite to the telephone.
The radios participating in the call stay on the trunked channel during the call hang time. A radio can
initiate a transmission during the call hang time. In a call involving multiple sites, radios at different
sites can initiate voice transmissions near simultaneously. A Capacity Max system uses a floor
arbitration algorithm, which selects one of the radios for transmission.
The floor arbitration algorithm is a proprietary feature and is used only by Motorola Solutions radios
when they are operating in a Capacity Max system. For non-Motorola Solutions radios, some
transmissions have more than one radio transmitting over each other. The probability of this increases
as the number of non-Motorola Solutions radios increases.
In some trunked radio systems, radios that need to transmit during hang time move to the control
channel and request permission. The system arbitrates with any other requests received from other
radios for the same call and provides a grant or reject. The disadvantage is that the request for every
transmission reduces the inbound capacity (that is, the number of calls initiated per hour) of the control
channel. For example, if a call has on the average 2.5 transmissions and the inbound capacity is
12000 random accesses per hour, the request for every transmission reduces the capacity to 4800
calls per hour.
28
MN003523A01-AC
1.3.8
Call Termination
A Capacity Max system allows a radio user to terminate a call.
A call is terminated if one or more of the following conditions occur:
• A radio can initiate a “call end request” during hangtime on the trunk channel where the call is
ongoing.
- In a talkgroup call, only the call initiating radio (that is, a radio whose request for the call was
granted) can initiate a call end request.
- In an Individual call, either the source radio or the target radio can initiate a call end request.
This feature improves the channel utilization, especially in case of a long call hangtime.
• The Call Hangtime has expired because no radio initiated transmission during the call hangtime.
• The Time Out Timer (TOT) of either the radio or the repeater has expired.
1.4
Capacity Max Voice Talkgroup Call
This section describes features that are common to processing of services, as well as features related
to talkgroup calls.
Overview
In a Capacity Max system, a talkgroup can be selected in any of the following ways:
• A Capacity Max radio supports multiple personalities that can be selected using knob position. A
personality has a “contact name”. A radio user can make a call to the contact name by just pressing
the PTT button. If the contact names of multiple personalities of a radio are talkgroups then the
radio user can select a talkgroup using the knob.
• A Capacity Max radio supports an address book. A radio user can make a call to an entry in the
address book using the radio’s menu. This can be done even when the radio is receiving a call.
• A personality has a “group list”. The group list can have up to 16 talkgroups. A radio user can
receive a voice or data group call, only if it is for one of the 16 talkgroups and scan is enabled or it is
for a All talkgroup, that is site-wide or multi-site or system-wide.
1.4.1
List of Valid Sites
A Capacity Max system allows a system owner to list the sites that are valid for a talkgroup.
For a talkgroup call (including multi-site all call talkgroup), a system owner can list the sites where a
call for the talkgroup can be initiated. A call for the talkgroup cannot be initiated from a site that is not in
the list. In addition, a call for the talkgroup is never transmitted over the air at a site that is not in the
list. By default, the list of valid sites for a talkgroup contains all sites.
This list allows a system owner to bill its customers based on the coverage area of a talkgroup.
If a radio requests registration and affiliation of its Tx talkgroup (contact name) at a site that is not in
the list of valid sites for the talkgroup, the system registers the radio, but with a warning. The radio
displays the warning, which may prompt the radio user to either roam manually to another site or use
the knob to select a different talkgroup (if configured). The radio is not able to make a call to its Tx
talkgroup (contact name), but it can do the following:
• Receive calls for its Rx talkgroups in the “group list” that are valid at the site.
• Make or receive individual voice or data calls.
29
MN003523A01-AC
• Make a call to a talkgroup (including an emergency talkgroup) that is valid at the site.
1.4.2
List of Static Sites
A Capacity Max system allows a system owner to list sites where a talkgroup call is always transmitted
over the air.
A call for the talkgroup is always transmitted over the air at all the sites in the list of static sites even
when no radios have affiliated at the site. By default, the list of static sites for a talkgroup contains no
sites. All sites in the list of static sites must be in the list of valid sites for the talkgroup. In other words,
the list of static sites is a subset of the list of valid sites for a talkgroup.
Affiliation of a talkgroup by a radio is an optional DMR Tier III feature, and some non-Motorola
Solutions radios may not affiliate their talkgroup. In that case, the system owner can statically
associate their talkgroup to the required sites.
Normally, emergency talkgroups are exclusively used for emergency purposes. If no radios affiliate for
the emergency talkgroup at a site then, and the emergency call cannot be transmitted at a site where
recipient radios are not present. In that case, the system owner can either statically associate their
talkgroup to the required sites or configure the emergency talkgroup into the radio's RX Group List as
an affiliation talkgroup..
Static site associations should be used judiciously because transmitting a talkgroup call at a site where
no listeners are present is a waste of channel resources.
1.4.3
Sites with Successful Affiliation
A talkgroup call is transmitted at all sites where at least one radio has successfully affiliated to the
talkgroup.
A radio affiliates to zero to seven talkgroups at a time. The radio affiliates its Tx member (contact
name) only if it is a talkgroup (excluding site-wide or multi-site All talkgroups). It affiliates to priority
talkgroups when they are configured/selected. The configured/selected affiliation talkgroups must
belongto the RX Group List.The system rejects affiliation of any talkgroup that is not valid at the site.
1.4.4
Talkgroup Call Affiliation
A talkgroup call can be initiated from any valid site for the talkgroup.
Affiliation is required for receiving a call, but not for initiating a call. Thus, a radio can initiate a call from
a site even when no radio has affiliated to the talkgroup at that site.
A talkgroup call is transmitted at all the valid sites for any of the following conditions:
• The site is statically associated with the talkgroup.
• At least one radio has affiliated to this talkgroup.
• The site is the source site.
1.4.5
Broadcast Talkgroup Call Configuration
A Capacity Max system allows a talkgroup to be configured as a Broadcast Talkgroup Call.
“Broadcast” is an attribute of a talkgroup call. A Capacity Max system sets this attribute to a usage (for
example, a transmit member (contact name) of a personality, an entry in the address book) of a
talkgroup. An address book can have two entries for a talkgroup – one with broadcast and other
without broadcast.
30
MN003523A01-AC
In a broadcast talkgroup call, only the initiating radio transmits. The call has hangtime (same as a
talkgroup call) but during hangtime only the call initiating radio can transmit.
Other participating radios cannot interrupt a broadcast call.
Normally, a large number of radios are members of a broadcast talkgroup. By not allowing other radios
to transmit during hangtime of a broadcast call, over the air collisions of responses of the other radios
can be eliminated.
1.4.6
Radio Joining an Active Talkgroup Call
There are certain scenarios where a radio affiliates to a talkgroup at a site and the in-progress
talkgroup call is not active at the site. Such scenarios include roaming to the site and changing the
selected personality of the radio. When a radio affiliates to an active talkgroup at a site and the
talkgroup call is not active at the site, the talkgroup call is routed to that site( if a traffic channel is
available).
NOTICE: If the radio affiliates to a list of talkgroups, the system attempts to join only the highest
priority affiliated talkgroup call
If a traffic channel is available, the control channel transmits channel grants and the radio joins the in-
progress call. If this addition of a site equals the threshold to use the voice replicator, the call switches
to use the voice replicator.
1.5
Capacity Max Individual Voice Call
This section describes the additional features related to Individual calls.
Overview
An individual call is a voice call between two entities, where both entities have non-reserved radio IDs.
In Capacity Max, other than a radio, a voice application (for example, console) has a radio ID and
an individual call may be between a radio and a console.
The DMR III standard has reserved some of the IDs between FFFECO16 and FFFFFF16. These IDs
cannot be used for a radio.
In Capacity Max, an individual call is transmitted over-the-air at one or two sites. It is transmitted at one
site if the source and the target radios are at the same site, or the source or the target is a voice
application.
1.5.1
Individual Call Types
In Capacity Max system, an individual call starts only after ensuring the availability of the destination.
Capacity Max system supports the following types of individual calls:
OACSU (Off Air Call Set Up)
An individual call is set up after checking the availability of the destination radio.
FOASCU (Full Off Air Call Set Up)
An individual call is set up after checking the availability of the user of the destination radio, and the
user indicates willingness to accept the call.
FOACSU and OACSU improve the reliability of the Individual calls. Once an Individual call is set up,
there is a very small probability that the target radio will not participate in the call. The advantage of
FOACSU over OACSU is that the FOACSU provides additional control of accept or refuse to the user
31
MN003523A01-AC
of the destination radio. The disadvantage of FOACSU is that it requires additional signaling over the
control channel.
Capacity Max does not support a PATCS (Push And Talk Call Setup) individual call. A PATCS call is
set up without checking the availability of the destination.
NOTICE: The destination may not be in a state, such as out of coverage or in another call, to
receive the call and therefore the PATCS calls may waste channels.
1.5.2
Individual Call Control
A Capacity Max system allows the system administrator to control the individual call capability of a
radio.
Using Subscriber Access Control (SAC), a system administrator can enable or disable a radio’s
capabilities as follows, including voice application:
• To receive an individual voice call
• To initiate an individual voice call
A Capacity Max system also allows a system administrator to select between OACSU and FOACSU,
and the selection is for the whole system. It is applicable to all individual voice calls except telephone
call. A single selection for all individual voice calls provides a consistent experience to the user.
NOTICE: As per DMR III standard, the source radio of an individual call cannot specify the call
setup method in the call request.
1.5.3
Individual Call Initiation
A Capacity Max system allows a radio user to initiate an individual call in three ways, as follows:
Manual Dial
A radio user can manually dial the ID of the target radio. This option can be turned on or off via
CPS. Manual dialing is possible only from a radio having display.
Address Book Dialing
The target radio has an entry in the address book and the radio user selects the target radio using
the address book. Address book dialing is possible only from a radio having display.
One Touch Dialing
A radio user pushes a programmable button of the radio to dial a pre-programmed radio ID.
The following are some other salient features of an individual calls:
• A radio in Emergency state does not participate in an individual call.
• A stunned radio does not participate in a voice individual call.
• An individual voice call can be terminated either by the source radio or the target radio.
• A Capacity Max system allows a system administrator to configure a hang time for individual calls.
The hang time is independent of the hang time for talkgroup calls.
32
MN003523A01-AC
1.6
Capacity Max Voice All Call
This section provides additional features related to All Calls.
Overview
The section on Capacity Max Voice and Data Services Over Trunked Channels on page 24 describes
the features that are common to processing of services.
An All Calls is a broadcast voice call between a call initiating entity and all the entities present at a
location where:
• An entity (for example, a radio, a voice application, or a data application) has a non-reserved radio
ID. The DMR Tier III standard has reserved some radio IDs between FFFECO16 and FFFFFF16.
• A location could be a site, a set of sites, or all sites in a system.
• A Capacity Max system does not support a data call to a site, a set of sites, or all the sites.
Like a talkgroup call, a broadcast call has a hangtime, but only the call initiator can transmit or
terminate a call during that hangtime.
1.6.1
Voice Site-Wide, Multi-Site, and System Wide All Call
A Capacity Max system supports a voice site-wide, multi-site and system wide All Call.
An All Call whose location is a site (called site-wide All Call) is received by the radios at the specified
site only. For an All Call initiated by a radio, the specified site is the site of the initiating radio. For an All
Call initiated by an application, the application explicitly specifies the site.
An All Call whose location is a set of sites (called multi-site All Call) is received by the radios at the
specified sites. As in a normal talkgroup, the system administrator can configure the sites that are
statically associated with the multi-site All Call group using Radio Management (RM). The DMR
specification supports only one multi-site All Call group.
Capacity Max utilizes a range of 128 Talkgoups (0xFFF60 to 0xFFFDF) to support multiple
preconfigured multi-site all calls. A radio or a third party application may initiate a call to any of the
multi-site All call IDs.
An All Call whose location is all the sites in a system (called system-wide All Call) is received by the
radios at any sites.
Multi-site and system-wide All Calls including more than 15 sites utilize the voice packet replicator
functionality in the MNIS VRC. When a replicator is not present in the system because (for example
due to a failure), calls including more than 15 sites are not supported.
1.6.2
Control of All Call Capability for a Radio
A Capacity Max system allows the system administrator to control the All Call capability of a radio.
Using Subscriber Access Control (SAC), a system administrator can enable or disable capabilities for a
radio (including the voice application) to initiate a site-wide or multi-site All Calls.
There is no control on reception of an All Calls. All radios are expected to receive All Calls.
33
MN003523A01-AC
1.6.3
Late Join Capability
A radio, which is participating in a call, may join an all call late. An All Call is announced over all busy
trunked channels of the sites that are associated with the All Call. The announcement causes the
radios listening to non-emergency calls to move to the channel where the All Call is in progress.
The following radios may either fail to join an All Call or join the All Call only after their call ends:
• Transmitting radios: While transmitting, a radio cannot listen to an announcement.
• Radios on the data revert channel: Announcements are not made over data revert channels.
• Radios participating in an emergency call: An emergency call has higher priority than an All Call.
1.6.4
Limit to Active All Calls at a Site
A Capacity Max system allows only one All Call to be active a time at each site. For example, if a site-
wide All Call is active at a site, the system rejects a request to initiate a multi-site All Call associated
with that site.
The DMR III standard provides one unique ID to each type of All Call: site-wide, multi-site, and system-
wide.
While an All Call is in progress at a site, only emergency calls are allowed to start from the site. Non-
emergency call requests from the site are discarded.
Some other features of All Calls are:
• A radio initiates an All Call in the same way as a talkgroup call.
• In Capacity Max, a request for an All Call is never queued. If a channel is not available at a required
site, the system pre-empts an ongoing non-emergency call. If all available channels are busy with
emergency calls, the request for an All Call is rejected.
1.7
Capacity Max Telephone Voice Calls
This section describes the telephone voice calls in Capacity Max, defines the different telephone call
types such as radio to telephone, telephone to radio, and telephone to talkgroup calls, and briefly
describes the telephone architecture and the supported telephone interface. The dialing method,
access code, overdial, and radio telephone capability control are also explained in this section.
Overview of Telephone Architecture and Supported Interface

The telephone voice calls are supported via the MNIS VRC Gateway. A compatible 3rd party telephone
application is required to be connected to the MNIS VRC Gateway. The landline telephone user
communicates with the radio users via the telephone application and the MNIS VRC Gateway.
Capacity Max supports the following two types of interface between a radio and the system:
• Radio sends the target telephone number over a traffic channel as in-band DTMF tones. This is a
Motorola Solutions proprietary feature and therefore 3rd party radios are not able to use it.
• Radio sends the target telephone number over the control channel as per DMR standard. This is
the standard way of setting up a telephone call and therefore it is supported by the 3rd party radios.
The main difference between the two methods is the call setup procedure. The messages used for
ending the call are different, but it is transparent to the users. The call types supported, the priority of a
telephone call, and encryption capability are the same. Once on the payload channel, the telephone
call uses the same types of signaling, including DTMF overdial from the radio.
34
MN003523A01-AC
System level parameter Phone Call Setup Method allows the user to select the method during
configuration.
1.7.1
Telephone Voice Call Types
The following three telephone call types are supported:
Radio to Telephone
Individual telephone call initiated from a radio user to a landline telephone user.
Telephone to Radio
Individual telephone call initiated from a landline telephone user to a radio user.
Telephone to Talkgroup
Talkgroup telephone call initiated from a landline telephone user to a group of radio users.
Telephone All Call, as a special telephone to talkgroup call, is also supported.
The priority of a telephone call is the same as a regular voice call type of the same talkgroup or
individual involved in the call. That is, for an individual telephone call, it is the same as a regular
individual voice call; for a talkgroup telephone call, it is the same as a regular talkgroup voice call of the
talkgroup involved. The telephone call can be either clear or encrypted, and there is no concept of
emergency telephone calls.
1.7.2
Methods of Dialing
The radio supports the following dialing methods:
Manual Dial
The radio user can manually dial the telephone number. This option can be turned on or off via
Radio Management. This feature is applicable for display model only.
Address Book Dialing
A radio user selects the telephone number from the radio’s telephone address book. This feature is
applicable for display model only.
One Touch Dialing
A radio user pushes a programmable button of the radio to dial a pre-programmed telephone
number.
The dialing method from the landline telephone user to a radio or a talkgroup is defined by the 3rd
party telephone application. Usually, the landline telephone user will dial a telephone number to the
telephone application, after connecting, the telephone user will be prompted to enter the target
Talkgroup ID or radio ID.
1.7.3
Telephone Call Answering
When a radio user calls a landline telephone user, the telephone user can pick up the telephone and
answer the call like a regular telephone call. When a landline telephone user calls a radio user or a
talkgroup, and if the target radio user, the talkgroup or a channel is available, the radio or talkgroup will
jump to the assigned channel and start the telephone call.
1.7.4
Telephone Call Handling
The telephone call in the radio system is a half-duplex call, unlike a regular duplex telephone call,
where the user (telephone or radio user) cannot talk and listen at the same time. A priority is given to
the radio users; when a radio user starts to talk, the system will automatically mute the landline
35
MN003523A01-AC
telephone user’s voice, and when the radio user is not talking, the landline telephone user can start to
talk.
1.7.5
Overdial
Overdial is necessary when further information in the form of DTMF digits is required after the
telephone call is established. Overdial is supported by the display radio models. For example, if a user
calls a company with a telephone voice prompt system, like a bank, once the call is connected the user
may be required to key in numbers or characters which is known as overdial, in order to navigate the
system.
1.7.6
Telephone Call Ending
The telephone call can be ended either by the radio user or the landline telephone user in the following
ways:
DTMF-based dialing
Radio user uses the de-access code to end the call. The radio user can provide the de-access code
either manually from the keypad or by pushing a (programmable) button. The de-access code is
sent over the air as DTMF tones.
DMR-based dialing
Radio sends a command to end a call. The de-access code should not be configured on the
application or the system.
Landline telephone user
End the call by hanging up or other methods defined by the 3rd party telephone application.
1.7.7
Radio Telephone Capability Control
The system administrator can control a radio’s telephone capability from the Subscriber Access Control
(SAC) in the following ways:
• Radios that can initiate telephone calls
• Radios that can receive telephone calls
• VRC gateway and thus the telephone application, a particular radio uses to initiate telephone calls
• Whether a telephone ‘All’ call can be initiated from a particular telephone application
1.7.8
Radio User Call Type Permissions Control
The system administrator can control a radio user’s capability to initiate certain type of calls such as
international, 1–800, 1–900, and others, with the use of an access code. An access code can be pre-
configured in a radio or can be left blank, for the radio to prompt the radio user upon telephone call
initiation. The access code is sent to the telephone application, where it is checked if the initiating radio
has the permission for the attempted telephone call type. There is only one access code for a radio per
system, and the access code is sent as in-band Dual Tone Multi Frequency (DTMF) tones.
36
MN003523A01-AC
1.8
Capacity Max MNIS Voice and Radio Command (VRC) Gateway
This section briefly describes the MNIS VRC Gateway and the services it supports.
Overview
The MNIS VRC Gateway is a software service, which resides in the Capacity Max System Server
(CMSS), and connects to Capacity Max repeaters over an IPv4 network. As it is connected with
repeaters over IPv4, wireless control stations are not required by the applications, when they are using
a MNIS VRC Gateway.
Wireline voice applications, such as the voice dispatch, voice recorders, and telephone gateway,
require MNIS VRC Gateway to communicate with a Capacity Max system. Some non-voice wireline
applications, which uses radio commands for emergency alarm monitoring, or stun or revive of a radio,
also require MNIS VRC Gateway. The applications connect to the MNIS VRC Gateway over the IPv4
network.
Applications can send or receive the following types of calls via the MNIS VRC Gateway:
• Group voice calls, broadcast group calls, site all calls, multi-site all calls, system wide all calls, and
emergency calls
• OACSU and FOACSU individual voice calls, remote monitor voice calls
• Telephone initiated group calls and individual telephone calls
• Radio check, call alert, radio stun or revive, radio kill, and emergency alarm
• Status Messages
• Receive Individual voice calls for recording or monitoring. All audio is monitored/recorded by
external voice applications such as the voice dispatch, telephony, and audio logging (including
Discreet Listening).
The application can also support MOTOTRBO’s end-to-end encryption feature for secure voice
communication between the radios and the application. Applications can interrupt a transmitting radio
and transmit over the radio. A transmission request during hang time from an application has higher
priority than the transmission requests from radios. A system administrator can set the higher priority
for the application’s call requests that are waiting for channels.
In addition to the Voice and Radio Command (VRC) gateway service, a CMSS with a TC supports a
voice packet replication service.
1.8.1
Gateways Architecture
A MNIS VRC Gateway can have a backup gateway for fault tolerance. Based on the information
provided by the MNIS VRC Gateway, an application can switch-over to the backup gateway upon loss
of network connection or failure of the primary gateway. Primary and backup gateways can be either
co-located or located at different locations for geographical redundancy. A Capacity Max system
supports up to 15 pairs of primary and backup MNIS VRC Gateways. Some voice dispatch applications
also support redundancy with backup applications, and the redundant application takes over upon loss
of network connection or failure of the primary application. The number of MNIS VRC Gateways
supported in the system is licensed. If two or more MNIS VRC Gateways are licensed then they can be
assigned as primary or backup pairs or as separate gateways.
The number of concurrent voice calls (that is, active talkpaths) supported by MNIS VRC Gateways in a
Capacity Max system is also licensed. A MNIS VRC Gateway can be allocated up to 100 talkpaths.
The MNIS VRC Gateway keeps a count of the number of talkpaths it is utilizing. The MNIS VRC
Gateway rejects a request from a voice application if the request causes the current number to exceed
the allocated number. An incoming voice call is not delivered to the voice application if the call causes
37
MN003523A01-AC
the current number to exceed the allocated number. The backup MNIS VRC Gateway does require
additional talkpath licenses. The radio commands do not require talkpath license. A MNIS VRC
Gateway allows radio commands even when it has zero talkpaths allocated to it. There is no limitation
on number of concurrent radio commands.
A MNIS VRC Gateway can support up to 10 independent applications such as the voice dispatch,
voice recorders, or telephone gateways. A voice dispatch applications have client-server architecture,
where the server connects with the MNIS VRC Gateway and multiple operator positions connect to the
server as clients. A server accounts as one of the ten applications the MNIS VRC Gateway supports.
1.8.2
Call Flow
An application that needs to participate in a voice call (for example, the voice dispatch) requires a radio
ID, and therefore an entry in the Subscriber Access Control (SAC). Using the SAC entry in Radio
Management, a system administrator can control the services permitted to the application.
The application registers its ID with the Capacity Max system via the MNIS VRC Gateway. The system
uses the registration for routing individual voice call or radio command from a radio to the MNIS VRC
Gateway, and the MNIS VRC Gateway uses the registration info to route the individual voice call or
radio command to the application.
A site ID is associated with a MNIS VRC Gateway and its backup. To receive a talkgroup call, the site
ID of the MNIS VRC Gateway is statically associated with the talkgroup in Radio Management. The
system routes a talkgroup call to a MNIS VRC Gateway, only if the site ID of the MNIS VRC Gateway
is associated with the talkgroup. An application affiliates a talkgroup to a MNIS VRC Gateway, which
uses the affiliation to route the talkgroup calls to the application. The MNIS VRC Gateway allows
multiple applications to affiliate for the same talkgroup.
A voice recorder subscribes the following with its MNIS VRC Gateway:
• A list of talkgroups, whose calls it wants to record. The list of talkgroups contains only single
talkgroup IDs (for example, TG 9, TG 235, TG 189).
• A list of source radios, whose calls it wants to record. The list of radios contains only range of radio
IDs (for example, 1-2000, 6700-6780).
The MNIS VRC Gateway routes the group voice calls and individual voice calls from the radios, whose
IDs are in the lists, to the voice recorder.
A telephone gateway subscribes a list of source radios, containing a range of radio IDs, whose served
telephone calls is with its MNIS VRC Gateway.
A MNIS VRC Gateway supports up to 1000 group affiliations, assuming that on the average 3
applications affiliates for a talkgroup. A MNIS VRC Gateway supports up to a total of 5000 radio ID
registrations from dispatch applications, and 32 ranges of radio IDs per recorder or telephone gateway
application.
1.8.3
Voice Packet Replication
A CMSS with a TC supports voice packet replication in its MNIS VRC gateway.
NOTICE: A standalone VRC gateway on a CMSS does not support replication
This functionality is automatic and does not require the purchase of a VRC gateway license. Voice
packet replication occurs under the following scenarios:
• Voice and Data Calls that include 16 or more sites,
• Voice and Data Calls to 3 or more sites where at least one site is configured by Radio Management
to require voice packet replication (Centralized Distribution checkbox is selected).
38
MN003523A01-AC
In general, configuration of a site to require voice packet replication lowers the link bandwidth
requirements at the configured site while increasing the link bandwidth requirements at the replicator
site. Although any CMSS with a TC supports replicator functionality, under normal operating conditions
the VRC gateway on the same CMSS as the active TC is used for voice packet replication.
However, under certian failure scenarios a CMSS with a non-active VRC gateway may be utilized for
replication. This means that the link bandwidth requirements at any site with a CMSS supporting TC
functionality must account for replicator loading. The system supports replication of up to 400 inbound
simultaneous voice streams through the replicator. To require voice packet replication at a site, select
the Centralized Distribution checkbox for the site in Radio Management.
1.9
Capacity Max MNIS Data Gateway
This section briefly describes the MNIS Data Gateway and the services it supports.
The MNIS Data Gateway is a software service, which resides in a Windows based PC and connects
with Capacity Max over an IPv4 network. It connects with repeaters over the IP network, therefore
wireless control stations are not required by the application when using the data gateway.
1.9.1
Data Applications
Data applications such as text messaging servers, location servers, telemetry, over the air
programming, and over the air battery management, require a data gateway to communicate with a
Capacity Max system. The applications communicate with the MNIS Data Gateway over the IPv4
network.
Data applications can send or receive the following types of Layer 2 data packets via the MNIS Data
Gateway:
• Unconfirmed data calls to or from a group
• Confirmed and unconfirmed data calls to or from an individual radio
• Receive high efficiency location data from a radio
Encryption can be enabled for secure data communication between the radio(s) and the MNIS Data
Gateway.
A MNIS Data Gateway supports transmission of data to radios over the trunked channels and
reception of data from the radios over the trunked channels, and enhanced GPS revert channels. The
MNIS Data Gateway can directly transmit data to or receive data from repeaters at a site of the
Capacity Max system. This eliminates the need for deploying wireless control station within the RF
coverage of a site. In Capacity Max system, rather than requiring channels at other sites, an enhanced
GPS revert channel always works in single site mode. Therefore individual data calls to data
applications only use channels at the radio’s source site. This improves the overall data capacity of the
system when utilizing the data gateway. As the MNIS Data Gateway can transmit or receive data from
any site; radios can roam to any site and are still able to communicate with the data application.
Capacity Max supports up to 15 MNIS data gateways per system, where each may have a paired
redundant MNIS data gateway. When supporting MNIS data gateway redundancy, both the primary
and the redundant gateways of the pair must reside on their own Windows OS server. In a redundancy
deployment the application cannot reside on either of the gateway servers. Deployment options for a
single MNIS data gateway are:
• Application(s) and MNIS data gateway installed on same PC (Windows OS server)
• Application(s) and MNIS data gateway installed on different PCs
For more details, see Capacity Max System Planning on page 107 and Application Deployment
Options on page 141.
39
MN003523A01-AC
1.10
Capacity Max Data Revert Channel
This section describes the capabilities of the Enhanced GPS Revert channel supported in Capacity
Max.
Overview of Enhanced GPS (EGPS) Revert Channels

A Capacity Max site supports up to 12 Enhanced GPS Revert channels (that is, six EGPS Revert
repeaters) for radio to server data. These channels increase the supported call load without impacting
call loading on the trunked channels. The Enhanced GPS Revert channel supports two types of data
payload format, which are IP Data and High Efficiency Data. Unlike other wide area solutions, in
Capacity Max an Enhanced GPS Revert Channel is not shared across all sites (wide area), rather it is
local to the site.
1.10.1
Enhanced GPS Revert Channel for IP Data
IP Data can be sent on the Enhanced GPS Revert channel via unconfirmed clear and unconfirmed
private (encrypted) radio to server location data. The location data can be indoor location or outdoor
location. This type of channel schedules the location updates of a radio into a time window.
Data reliability is primarily a function of repeater loading, when a radio misses its scheduled update
when involved in a call, and RF conditions. The duration of the time window (that is, the window size) is
a function of the amount of data requested by the location server. Third-party developers can provide
which window size they require for their location server. This type of channel supports update rates of
30 seconds, 1 minute, 2 minutes, 4 minutes, and 8 minutes where the channel loading can be set to
limit at 90%, 75%, 60% or 45%.
The following table shows the number of updates per minute per channel for Window Size and
Channel Loading Limit. Refer to Number of Data Revert Repeaters Selection on page 140 for guidance
on the Channel Loading Limit. The update rate does not need to be the same for all radios operating
on the enhanced GPS revert channel. The typical window size is 7, and the typical channel loading is
75%.
Table 2: Number of Updates per Minute per Channel (Slot)
Number of Updates per Minute per Channel (Slot)

Window Size 90% 75% 60% 45%
5 180 150 120 90
6 150 125 100 75
7 128 107 86 64
8 112 93 75 56
9 100 83 66 50
10 90 75 60 45
1.10.2
Enhanced GPS Revert Channel for High Efficiency
High Efficiency Data can be sent on the Enhanced GPS Revert Channel via unconfirmed clear radio to
server outdoor location data as well as radio to server raw data from an XCMP connected device.
Typically the XCMP connected device is the Option Board. High Efficency Data does not support data
40
MN003523A01-AC
privacy (encryption). This type of channel schedules the High Efficiency Data of a radio into a time
window.
Data reliability is primarily a function of repeater loading, when a radio misses its scheduled update
while involved in a call, and RF conditions, though other parameters can impact. A window size of one
is used when the server is connected through the MNIS Data Gateway, and a window size of two is
used when the server is connected through a wireless control station. This type of channel supports
update rates of 7.5 seconds, 15 seconds, 30 seconds, 1 minute, and 2 minutes.
The following table shows the number of updates per minute per channel for Window Size and
Channel Loading Limit. The update rate does not need to be the same for all radios operating on the
enhanced GPS revert channel.
Table 3: Number of Updates per Minute per Channel (Slot)
Number of Updates per Minute per Channel (Slot)

Window Size 90% 75% 60% 45%
1 900 750 600 450
2 450 375 300 225
For data through an Over-The-Air (OTA) Data Gateway, high efficiency data signaling carries longitude
and latitude information to the application.
For data through an MNIS Data Gateway, high efficiency data signaling supports options that carry the
following limited information to the application:
• longitude, latitude, horizontal speed (138 mph maximum), direction and time
• longitude, latitude, pin status and time.
If the customer requires more information than high efficiency data can support, then IP data must be
used.
Enhanced GPS Revert Channel Data Payload Format Comparison Chart

Revert Data Relia- Supports Data Types Location Pa- Supported
Channel bility Privacy (En- Supported rameters Radios per
Type cryption) Time Slot
IP Data Unconfirmed Yes Outdoor Lo- Full 107 (1)
cation and
Indoor Loca-
tion
High Efficien- Unconfirmed No Outdoor Lo- Limited 752 (2)
cy Data cation and
OB Data
(1) 1 minute update rate with window size of 7 and 75% loading
(2) 1 minute update rate with 75% channel loading through MNIS Data Gateway
1.11
Capacity Max Location Services
This section describes how to determine the Capacity Max radio’s location. A Capacity Max radio’s
location may be tracked indoors, outdoors or both with appropriate radio hardware, 3rd party hardware
support for indoor location only, and 3rd party application support. The third-party applications connect
41
MN003523A01-AC
into the radio network via an IP Data Gateway or OTA Data Gateway. Radios can send their location
data to the third party application on a trunked channel, a data revert channel or, an Enhanced data
GPS (EGPS) revert channel.
Overview
The MOTOTRBO location feature allows a dispatcher to determine the current location of a radio on a
display map. The dispatcher can obtain the radio’s location (latitude or longitude), or the location
combined with other information about the environment such as horizontal speed, direction, and
others, that allows value-added services, like tracking of resources.
Location Services via Global Navigation Satellite System

MOTOTRBO systems enable location services via two complementary functions. Firstly, the
MOTOTRBO mobile and portable radio portfolio, which includes models that are equipped with a built-
in Global Navigation Satellite System (GNSS) receiver. The acquisition of location data is done by a
GNSS receiver inside the radio, and is dependent on the GNSS receiver receiving accurate signals
from the earth-orbiting GNSS satellites. However, the GNSS receiver may not work well indoors or in
environments, where the sky is largely obscured.
Secondly, the integrated data services capability of the MOTOTRBO system, allows well equipped
mobiles and portables to transmit their location coordinates over the radio system, to a receiving
application that displays radios geographic locations on a high resolution map. This third party
supported receiving application is the second part of the system and connects to the radio network
through an IP Data Gateway or OTA Data Gateway.
1.11.1
Global Navigation Satellite System (GNSS)
Based on the radio hardware, the following systems are supported for the outdoor location solution.
• GPS
• GLONASS
• Beidou
• Galileo
• QZSS
Some radio’s hardware supports multiples systems at once, and allows the selection of multiple
systems. This will reduce Time To First Fix (TTFF) in areas where multiple GNSS solutions exist, as an
increased number of satellites are now available.
GNSS Performance Specifications for GPS
Table 4: GNSS Performance Specifications for GPS
GPS Receiver Portable Mobile

TTFF (Time To First Fix) Cold < 2 minutes < 1 minute
Start
TTFF (Time To First Fix) Hot < 10 seconds
Start
Horizontal Accuracy < 10 meters
NOTICE: Accuracy specifications are for long term tracking (95th percentile values > 5 satellites
visible at a nominal -130 dBm signal strength).
The GNSS erformance specifications for GPS are described as follows:
42
MN003523A01-AC
Cold Start
A cold start scenario occurs when the radio is first powered up, and the GPS receiver is attempting
to acquire its first position lock. In this scenario, the GPS receiver only has a valid almanac stored;
it does not have any valid satellite ephemeris data nor valid real-time clock synchronization.
Almanac data is stored in a non-volatile (persistent) memory, and is valid for approximately one
year. The GPS receiver regularly updates the almanac data; therefore it will always be valid unless
the radio is powered off for more than one year. The almanac data provides a mapping of the GPS
satellites position in the sky in relation to a real-time clock.
Hot Start
A hot start scenario occurs when the GPS receiver attempts to acquire a new location fix after a
previous fix had occurred recently. In this scenario, the GPS receiver has valid satellite ephemeris
data, a valid almanac, and valid real-time clock synchronization.
TTFF
Time to First Fix indicates the time the GPS receiver takes to determine its first or subsequent
position lock. This is determined largely by the time taken to download a full satellite ephemeris or
satellite orientation packet with a data rate of 50 bits per second (bps), and how long it takes for the
GPS receiver to reach the relevant satellite in its Scan List. In a cold start, the Scan List includes all
of the 24 orbiting satellites. The GPS receiver samples each satellite for a certain amount of time to
determine if it is visible or not before moving to the next satellite. The receiver continues to do this
until it detects a certain number of visible satellites and can determine an approximate location,
thus helping the receiver to truncate the Scan List. In a hot start, the receiver already has most, if
not all, the data needed to calculate its position. Therefore, no scanning is needed and minimal
downloading is necessary to calculate position, resulting in a lower time to acquire a positional fix.
1.11.2
GNSS Services for Radio Users
When the GNSS location service is enabled, an icon is displayed on the radio. The absence of this
icon indicates that the location service is either disabled or radio does not contain a GNSS receiver.
The icon shows a full satellite dish when good GNSS signals are detected, and an empty satellite dish
when the radio is receiving poor GNSS signals.
Good Signal Poor Signal Disabled
no icon
Selected radio models allow users to view the current location information, through the front panel
menu by selecting Utilities -> Radio Info -> GPS Info. Displayed information includes longitude,
latitude, altitude, velocity and number of satellites of all selected GNSS systems.
With the exception of pressing the Emergency button, a radio user cannot trigger a location update to a
location application server. In general, the radio user does not have to take any action in this process,
as the radio transmits the location coordinates automatically over the system.
43
MN003523A01-AC
Location Services via Bluetooth Low Energy (BLE) and iBeacons (Indoor
Location)
The MOTOTRBO Indoor Location feature requires the radio to support BLE support, the installment of
iBeacons throughout the indoor area of interest, and the marking in the application of the iBeacon
locations. The radio periodically scans for iBeacon broadcasts, and sends this information to the
application where the radio’s location is triangulated. The radio does not support beacon technologies
other than iBeacon.
1.11.3
Services Provided to a Location Application
For all the services, a location application server is required to send an explicit request to the radio. A
radio does not provide unsolicited location update to a location application server. When the radio turns
on the radio registers with the system. The location application learns that this radio is on the air, and
will make an explicit request for location updates if it is configured to track the location of the radio. The
explicit request may be omitted if persistent LRRP is enabled in the radio. This reduces the amount of
server to radio messaging at power on.
Well equipped radios transmit an update of their location coordinates over the radio system in
response to 5 different service methods, as follows:
Single Location Update
The location application server wants to know the current location of a radio user. In this case, the
application sends a request for a single location update. Single location update is used to track the
location of a radio user by a location application server, but is an inefficient use of air interface.
Periodic Location Updates
Location tracking allows a location application server to periodically get the location of a radio user by
sending a single location request that contains the time interval between updates. The radio continues
to update its location periodically at the specified time interval until the request is cancelled by the
location application server.
On Emergency
A radio will send its location after the user triggers an emergency alarm or an emergency alarm and
call request. The location update is sent only to the location application server which had previously
sent an active location request for location updates from that radio upon an emergency event. This
location update is sent by the radio only after the processing of emergency is completed. For example,
for Emergency Alarm with Call, the location data is only sent after the emergency alarm is
acknowledged and the initial Emergency Call is completed. This happens because the location data is
sent as a data burst which has lower priority than the voice call.
Event Driven Update
Location tracking allows a location application server to get the location of a radio user by sending a
single location request that contains the event used to trigger an update. The radio updates its location
upon this event until the request is cancelled by the location application server. The supported event is
GPIO pin change.
Distance Driven Update
Location tracking allows a location application server to get the location of a radio user by sending a
single location request that contains the distance traveled between updates. The radio updates its
location after traveling the specified distance from the previous update until the request is cancelled by
the location application server.
See third party offerings for specifics on the services they provide.
44
MN003523A01-AC
Location Application Connection to the Radio Network

The location application connects into the radio network through either an IP data gateway or an OTA
data gateway.
1.11.4
Location Data Channel Types
Both indoor and outdoor location data can be sent on a trunked channel or an Enhanced GPS (EGPS)
Revert channel with a data payload format of IP Data. Outdoor location can also be sent on an
Enhanced GPS Revert channel with a data payload format of High Efficiency Data. When sending on a
trunked channel, the radio requests and is granted the channel using control channel signaling. This
method applies a load on the control channel and reduces the number of calls that can be supported at
a site. Sending location updates on a trunked channel is not recommended for sites supporting a high
volume of traffic. For high traffic volume sites it is recommended to use Enhanced GPS Revert
channels. EGPS Revert channels do not put any load on the control channel. Specifics on the EGPS
Revert channel can be found in Capacity Max Data Revert Channel on page 40.
1.12
Capacity Max Remote Monitoring
This section describes the Remote Monitoring feature which is also known as Ambient Listening.
Overview of Remote Monitor

Remote Monitor is a feature that allows the call initiator to activate a target radio’s microphone and
transmitter. The monitored target radio’s PTT is activated without giving any indication to the monitored
radio user, when the call is setup. If a radio is already in a call, the Remote Monitor request is not
queued.
A Remote Monitor call is a one way individual voice call, in which the monitored or the called radio un-
mutes its microphone and transmits the ambient sound for a configured duration on the trunked
channel.
Applications connected to an MNIS VRC Gateway ( for example, the Console) and radios can initiate a
Remote Monitor. A radio user can select a contact like an individual radio, from the menu and can
initiate Remote Monitor to that contact.
1.12.1
Radio Configuration
The remote monitor feature can be customized by configuring the radio using Radio Management. The
following are the configurations that can be done:
• The duration of the remote monitor call is configurable in the radio.
• The remote monitor feature can be enabled or disabled in the radio. When the feature is disabled,
the radio cannot be remotely monitored.
• The remote monitor feature can be enabled selectively, when the radio is in emergency mode;
therefore the target radio can only be remotely monitored, when it is in emergency mode.
1.12.2
System Server Configuration
The remote monitor feature has two controls for each radio ID in the System Access Control (SAC), of
the Capacity Max System Server (CMSS). One control is for initiating a remote monitor, and the
second control is for receiving a remote monitor. The system checks the following conditions during a
remote monitor call setup:
45
MN003523A01-AC
• The initiating radio ID is registered to the system

• Remote monitor capability is enabled in SAC for initiating radio ID
• The monitored radio ID is registered to the system
• Receive remote monitor capability is enabled in SAC for monitored radio ID
1.12.3
Remote Monitor Duration Recommendation
The monitored radio transmits for the configured remote monitor call duration; thus it is recommended
to keep the configured duration to a small value like 10 or 20 seconds, for efficient trunked channel
usage. Occasionally if it is required to monitor a radio for longer duration, remote monitor call to the
same radio can be initiated multiple times.
NOTICE: The target radio ends the remote monitor call, when the target radio user initiates a
call during remote monitor transmission.
1.13
Capacity Max Radio Check
This section describes the Radio Check feature.
Overview of Radio Check Feature

The Radio Check feature allows an application to determine if a radio is available in the system without
disturbing the radio user. If a radio is registered to the system, and is in contact on the control channel
at any site, the radio responds with an acknowledgment to the radio check. The Capacity Max system
performs the radio check once, and updates the initiator on the status of the radio check. The initiator
has to do the retries, if a radio check fails.
A Radio Check fails in any of the following conditions:
• The target radio is not registered to the system
• The target radio is in a call on a trunked channel
• The target radio is sending data on a data revert channel
• The target radio is out of RF coverage area or switched off
• The feature is not enabled in the Subscriber Access Control record of the initiating application.
Applications connected to a MNIS VRC gateway can initiate a radio check, while radios like the
subscriber units cannot initiate a radio check.
Configuration in the Capacity Max System Server (CMSS)

The Radio Check feature has to be enabled for the initiating application’s (for example, the console)
radio ID in the System Access Control (SAC) of the CMSS. The source radio ID and target radio ID
have to be enabled in the SAC. SAC configuration is not required for radio check receive functionality.
All radios receive the radio check by default.
46
MN003523A01-AC
1.14
Capacity Max Call Alert
This section describes the Call Alert feature.
Overview
The Call Alert feature allows a radio user or a dispatcher ‘A’ to send an alert to another radio user ‘B’,
where the radio user ‘A’ is requesting the radio user ‘B’ to call back the radio user ‘A’, when the radio
user ‘B’ becomes available. Voice communication is not involved in this feature. Call Alert is a Motorola
Solutions proprietary feature, and it is available in both Advantage Mode and Open System Mode. In
Open System Mode, both radios must be MOTOTRBO radios.
1.14.1
Call Alert Feature Description
To use the Call Alert feature, the calling radio user specifies the ID of the target radio. This can be
done in several different ways, such as the ID can be entered manually via the keypad, by selecting an
ID from a Unified Call List (UCL), or by using the Last Number Redial (if any).
On receipt of a Call Alert, the target radio plays an alert tone to the user and displays the calling radio’s
ID. The duration of the alert can be configured using Radio Management. The target radio user can call
back the Call Alert source by pressing PTT, by pressing PTT to talkgroup and having Call Alert go
straight to call log, or can clear the alert tone by pressing back or home key. While the target radio is
alerting its user, the target radio continues to send GPS transmissions (if any).
A Call Alert fails in any of the following conditions:
• Source or the target radio is not registered to the system
• Source radio does not have call alert enabled in the SAC
• Target radio is in other call on a trunked channel
• Target radio is sending data on a data revert channel
• Target radio is out of RF coverage area or is switched off
Call Alert Initiation

Applications connected to a MNIS VRC Gateway can initiate a Call Alert. Radios can also initiate Call
Alerts.
Call Alert Feature in Subscriber Access Control (SAC)

The Call Alert feature has to be enabled in SAC for the initiating radio or application (for example,
console) radio ID using RM. The system checks that the source and target radios are registered to the
system, and the call alert feature is enabled in SAC for the source radio before processing the call alert
request. There is no SAC configuration for receiving a call alert. All the radios receive a call alert by
default.
1.15
Capacity Max Emergency Handling (Alarm and Call)
This section describes the ergonomics of the initiating radio, the process of selecting an emergency
talkgroup, the ergonomics of receiving an emergency, the process of sending location on emergency,
and the feature interaction while in emergency. In addition, this section discusses how Capacity Max
prioritizes emergencies and describes the available emergency modes: Alarm Only, Alarm and Call,
and Alarm with Voice to Follow.
47
MN003523A01-AC
Overview
Capacity Max enables a radio user in distress to send an emergency alarm, and optionally emergency
voice, to a talkgroup monitored by a voice console operator. Upon reception of an emergency alarm,
the console provides an audible and visual indication of the emergency, and the initiating radio ID is
displayed. Depending on configuration, emergency voice may follow between the initiating radio and
the console operator. When the condition that led to the emergency alarm is resolved, the console
operator clears the alarm locally. When the initiating radio user clears the emergency on the initiating
radio, the emergency is terminated.
NOTICE: Radios can receive emergency alarms/calls. The talkgroup will be monitored by
another radio or voice application.
1.15.1
Emergency Initiation
Each mobile radio can program the emergency button to any of the programmable buttons, whereas a
portable radio can only use the orange button as the emergency button. An emergency can also be
triggered externally through a footswitch, a mobile application, or any other applicable accessory.
Pressing the emergency button causes the radio to enter emergency mode and begin its emergency
process.
1.15.2
Alarm Type
The alarm type determines the ergonomics of the initiating radio upon entry to emergency mode.
Regular
When a user initiates a regular emergency, the radio provides an audible and visual indication to show
that it has entered emergency mode. The audible indication is to notify the radio user of successful
entry to emergency mode.
Silent
When a user initiates a silent emergency, the radio suppresses all indications of the emergency status
on the initiating user’s radio. In addition, all received voice is muted. The voice is muted so that
responses from the voice console do not inadvertently indicate the emergency state. This feature is
valuable in situations where an indication of an emergency state is not desirable.
When the user breaks radio silence by pressing the push-to-talk (PTT) button and speaking, the silent
emergency ends, audible and visual indications return, and the radio returns to its normal unmute
rules.
Silent emergency has no effect on data. It is the responsibility of the end user to make sure data is not
sent to a terminal that would divulge any emergency state. Transmission of data does not clear a silent
emergency.
Silent with Voice

When a user initiates a silent emergency with voice, the radio suppresses all indications of the
emergency status on the initiating user’s radio, but received voice is not muted. This feature is valuable
in situations where an indication of an emergency state is not desirable.
When the user breaks radio silence by pressing the PTT button and speaking, the silent emergency
ends, and audible and visual indications return.
Silent emergency has no effect on data. It is the responsibility of the end user to make sure data is not
sent to a terminal that would divulge any emergency state. Transmission of data does not clear a silent
emergency.
48
MN003523A01-AC
1.15.3
Emergency Search Tone
When a user initiates an emergency, the radio provides a loud and attention grabbing tone. The tone is
to help people locate and identify the emergency initiator.
The emergency search tone starts when the emergency starts, and ends when the radio exits the
emergency. The tone is temporarily suspended when the radio is transmitting or receiving.
The tone is provided whether the “All Tone Disabled” option is activated or not. This tone is mutually
exclusive with the silent emergency setting.
The option can be configured to specify where to route this emergency search tone or incoming voice;
to the radio’s internal speaker or the accessory. When an accessory is not attached, the tone is routed
to the radio’s internal speaker automatically.
1.15.4
Emergency Talkgroup
Emergency alarms and emergency voice are addressed to a talkgroup. The selection of which
talkgroup makes a major difference in the overall operation of the emergency. The emergency
talkgroup is configured as the contact name in the emergency system set within Radio Management.
Tactical
Sending an emergency on the currently “selected” talkgroup (sometimes referred to as a “tactical”
emergency) allows everyone in the currently selected talkgroup to monitor the emergency situation.
Each talkgroup may have a dedicated dispatcher that handles emergency situations, or the entire
group may need to be notified that someone in the talkgroup is in emergency.
In a system with many talkgroups, a tactical configuration requires the dispatcher to monitor every
talkgroup for emergencies, which could become cumbersome. In addition, the remaining members of
the talkgroup must yield use of the talkgroup to the individual in emergency.
Reverting
Sending an emergency on a predetermined talkgroup (referred to as “reverting”) allows users to leave
their currently selected talkgroup and communicate to the dispatcher on a dedicated emergency
talkgroup.
This reverting function allows a dispatcher to monitor the dedicated emergency talkgroup and have all
other users revert to the dispatcher in case of an emergency. This function minimizes the possibility of
supervisors missing emergencies on one talkgroup while monitoring other talkgroups. It also allows a
clear channel of communication for the user initiating the emergency and the dispatcher. Other radio
users may not be aware of the emergency situation unless they monitor the dedicated emergency
talkgroup.
After the radio user clears the emergency, the radios revert to the talkgroup they selected before the
emergency occurred.
If the radios revert to a dedicated emergency talkgroup, that talkgroup must be statically assigned to
MNIS VRC and Data gateway sites. If the revert emergency talkgroup was not previously affiliated, the
radio affiliates to the emergency talkgroup before starting its emergency procedures.
1.15.5
Reception of an Emergency Alarm or Call
Emergencies are best received and handled at voice consoles. The larger display allows the
dispatcher to effectively handle numerous simultaneous emergencies. The methods vary depending on
console vendor.
49
MN003523A01-AC
Emergency Alarm Indication

The radio retains the last received emergency alarm. Once cleared, the emergency alarm is removed
from the radio. The channel where the emergency alarm was received is displayed to aid the
supervisor when changing channels. Delivery of emergency alarms is only confirmed inbound over the
air to the system. They are not confirmed outbound to the radios. Only radios with this option enabled,
and that are monitoring the control channel when the emergency alarm is initiated, provide the
emergency alarm indication.
Emergency Call Indication

If a user follows the emergency alarm with a voice call while in emergency mode, that user’s
transmission contains an embedded emergency indication. Radios can be configured to display this
embedded emergency indication when they receive an emergency call.
The indication is not persistent. The indication is only present while the radio is receiving an
emergency call.
1.15.6
Transmission of Location Information During an Emergency
A location equipped radio can send its location to a location data application when an emergency is
triggered. The location data application requests the radio to send location on the emergency event
when it requests periodic location updates.
1.15.7
Feature Interaction During an Emergency
When a radio is in emergency mode, features that may distract that user from communication with the
supervisor are blocked. For example, the user cannot initiate an individual call or talkgroup call from
the address book, or other command and control functions. In addition, any other receive talkgroups
that were previously configured for that user are not monitored.
When the radio exits emergency mode (for example, after the user turns the radio off and on, after a
long or short press of the emergency button, depending on the radio configuration), the features
blocked during the emergency return.
1.15.8
Prioritization of Emergencies
This section describes the methods used to prioritize emergencies within the system.
Call Preemption at Busy Sites

If no trunked channels are available, the system interrupts (pre-empts) ongoing calls and grants the
emergency call. If a radio is transmitting on the pre-empted channel at the same site as the emergency
initiator, the system directs that radio to immediately stop transmitting, which prevents interference with
transmissions by the emergency initiator.
Radio transmissions that were occurring on the pre-empted channels at other sites are not interrupted,
but their transmissions are not repeated. When any interrupted radio dekeys, it returns to the control
channel. Other calls are not interrupted.
Emergency Calls Announced on Trunked Channels

The system announces ongoing emergency calls in the embedded signaling of other ongoing calls.
This function allows radios to join the emergency call even while participating in other calls. In order to
use this feature, radios must have the emergency talkgroup as their primary talkgroup or in their
talkgroup receive list.
50
MN003523A01-AC
Longer Emergency Call Hangtime

The system allows for emergency calls to have a longer call hangtime than other talkgroup calls. A
longer call hangtime holds the assigned trunked channel longer. This function aids in call continuity
and decreases access time for in-call retransmissions. The emergency call hangtime is configurable
within Radio Management.
Increased Number of Channel Access Attempts

The system allows for emergency alarms and calls to have more channel access attempts than other
call types. Allowing more channel access attempts increases the opportunity for emergency calls and
alarms to access a channel during poor coverage or heavy call volumes.
1.15.9
Emergency Mode
This section describes the configurable methods to process an emergency.
Emergency Alarm Only

When configured for Emergency Alarm Only, the emergency process consists only of the emergency
alarm delivery. The emergency ends when an acknowledgement is received from the system, or when
channel access attempts have been exhausted. In most conditions, an acknowledgement is returned
from the system quickly. No voice call is associated with the emergency when operating as Emergency
Alarm Only.
Emergency Alarm and Call

When configured for Emergency Alarm and Call, the emergency consists of sending an alarm followed
by the ability to perform an emergency call. The emergency alarm delivery is complete when an
acknowledgement is received from the system, or when channel access attempts have been
exhausted. If the emergency talkgroup was not previously affiliated, the radio affiliates to the
emergency talkgroup before starting its emergency procedures.
When emergency alarm delivery is complete, the radio remains in an emergency state. Any follow-up
PTT initiates an emergency call.
An emergency call includes an embedded emergency indication. If the user presses the PTT button
before the radio sends an emergency alarm, the radio stops sending the alarm and starts the
emergency call. While in the emergency mode, all subsequent voice transmissions are emergency
calls.
The user remains in emergency mode until the user manually clears the emergency. The only way to
reinitiate the emergency alarm process is to reinitiate the emergency.
Emergency Alarm with Voice to Follow

When configured for Emergency Alarm with Voice to Follow, the emergency consists of sending a
single emergency alarm followed by an automatic transmission of an emergency call. This automatic
transmission is referred to as “hot microphone”. If the emergency talkgroup was not previously
affiliated, the radio affiliates to the emergency talkgroup before starting its emergency procedures.
The radio only sends one emergency alarm regardless of the presence or absence of channel activity,
and then without waiting for an acknowledgement, the radio immediately activates the microphone and
initiates an emergency call without the need of the user pressing the PTT button.
The duration of the hot microphone is configurable (TX Cycle Time). The transmission is considered an
emergency call and therefore includes the embedded emergency indication. Once this hot microphone
duration expires, the radio stops transmitting but remains in emergency mode. Any follow-up PTT
51
MN003523A01-AC
initiates an emergency call and includes the embedded emergency indication. The radio remains in the
emergency mode until the user manually clears the emergency.
1.15.10
Interaction Between Voice to Follow and Location on Emergency
When configured for Emergency Alarm with Voice to Follow, the radio continues to transmit voice for
the duration of the provisioned hot microphone timer (TX Cycle Time). Because voice has priority over
data, any data is queued while voice is transmitting, including the location update that triggered the
emergency. The location data cannot be delivered until after the radio stops transmitting voice and
after the repeater hangtime has expired. The location data has no additional priority over other data
queued in the radios, or over any traffic on the channel. Therefore, if the radio in emergency has
pending data queued or if the channel is busy processing other traffic, its delivery may be delayed.
When Emergency Alarm with Voice to Follow and location on emergency are in use, the hot
microphone timer should be set at maximum 30 seconds. Because data messages do not stay in the
queue forever, 30 seconds is short enough to give the location data a chance to be transmitted without
timing out. Also, if the hot microphone timer is set to an interval longer than 30 seconds, and the
location update rate is close to the same value, other location messages may start to fill up in the
queue while the voice transmission is processing.
When a user is transmitting during the hot microphone timer interval, there is no way to communicate
back to that user. Most users can explain their situation in less than 30 seconds and require some
feedback from the emergency dispatcher much sooner. Therefore, a short timer interval is
recommended, and if additional monitoring is required, the remote monitor feature can be utilized.
Long timer intervals should be used only in specialized applications.
1.15.11
Hot Microphone Cycles
The radio can be configured for one to ten hot microphone cycles. A cycle consists of a period of
transmitting with a hot microphone (TX Cycle Time) and a period of receiving (RX Cycle Time). One
cycle consists of the TX cycle time and the RX cycle time. This cycle time provides the dispatcher a
designated duration to respond to the initiator.
Use of short TX and RX cycle times (for example, one second) may result in voice being truncated as
the radio quickly and automatically cycles between transmit and receive. Use of longer TX and RX
cycle times (greater than ten seconds) may result in long wait times before the radio automatically
cycles, which means a long wait for responses. Implementing a hot microphone cycle may require
great discipline and practice between the radio users and the dispatcher. This feature should only be
used in specialized applications.
Any PTT during the hot microphone cycles initiates an emergency call. The next cycle resumes after
the release of the PTT. After the cycles have ended, the radio remains in emergency mode. The user
can manually clear the emergency to stop the cycles and exit emergency mode.
1.16
Capacity Max Multi-Site Roaming
This section describes the roaming feature, its aim, and sub-features in the Capacity Max multi-site
environment.
Overview
The roaming feature aims to reduce the disruption in the communication between the radio and the
infrastructure, when a user is moving from site to site. Both the radio and the infrastructure play a role
in roaming. In the radio, the roaming feature runs in the background with minimal interactions with the
user. The radio monitors the current active control channel of the current site that the radio registers
52
MN003523A01-AC
with and as necessary all the active control channels of the neighboring sites. The radio decides due to
various reasons, when to leave the current site and start searching for a better site.
The infrastructure plays a role in announcing the information about the neighboring sites, so that the
radio can search the sites from its neighborhood, before searching for the rest of the sites.
The radio may be engaged in a call while roaming and need to hand over the call. Capacity Max
supports a proprietary call handover for a voice talk group call that reduces any audio holes. This call
hand over is supported only when the radio is in a voice receiving or in a call hang time state.
The Capacity Max system supports roaming only among the sites that are configured into the radio or
learned through over the air announcement. Roaming between sites of a different network or system
types, or to an unknown / unconfigured site is not supported.
1.16.1
Multi-Site Network
From roaming perspective Capacity Max infrastructure is composed of networks, location areas, sites,
and control channels. A multi-site network has more than one site. A site can have one or more
candidate control channels, with one candidate control channel always being the active control
channel.
As defined in the DMR standard, several sites in a network can be grouped into a location area. In the
Capacity Max infrastructure, a location area consists of only one site for efficient channel usage. The
radio does not support location area configuration when it is used in a Capacity Max Advantage Mode
or Open System Mode. The radio provides location area configuration only when it is used in a
Capacity Max Open Radio Mode.
1.16.2
Site Neighborhood
At any point of time, the radio registers only with one site, and operates within its coverage. This site is
referred to as the home site and is defined as the site that the radio currently registers with. The rest of
the sites in the network are referred to as sites that are adjacent sites or non-adjacent to the home site.
Due to roaming, a radio may have a new site as its new home site, and thus new set of adjacent and
non-adjacent sites.
Site adjacency information is configured in the infrastructure. The radio learns this adjacency through
the Over-The-Air announcement, which is sent via the active control channel of the home site.
Therefore, the radio is able to recognize the sites that are adjacent and that are non-adjacent to the
current home site, every time the radio roams from site to site.
The home site, as well as the adjacent and non-adjacent sites reflect a dynamic site neighborhood
which changes following the radio roaming activity.
1.16.3
Received Signal Sampling
The radio periodically samples and measures the received signal strength of the active control channel
of the home site. When it is measured lower than the RSSI Sampling Threshold, a roaming procedure
is attempted by sampling all the active control channels of the adjacent sites, after each sampling of
the home site. When the signal strength of the home’s active control channel is higher or same as the
RSSI Sampling Threshold, the radio does not sample the active control channels of the neighboring
sites. This is because roaming is not needed. Sampling of the control channel is done without impact to
audio or control channel operation.
The radio validates and filters the raw sampled signal to prevent adverse effects of the signal
fluctuation on the roaming. The radio updates the last valid and filtered signal of home and each
adjacent site.
53
MN003523A01-AC
1.16.4
Roaming
Upon completion of one round of periodic signal sampling, the radio evaluates the favorableness of the
home and adjacent sites. If the home is sufficiently favorable, the radio stays at the home site. If there
is an adjacent site that is more favorable than the home site, the radio leaves the home site and starts
searching for a better site.
Various conditions and configuration parameters are considered in calculating the favorableness of a
site. Among those parameters are site preference level, site trunking condition, failures experienced by
the radio on the site, and the sampled received signal. In a regular scenario without involving any
failures, the sampled received signal is the main factor in determining the favorableness. The
decreasing or increasing strength of the sampled received signal indicates whether the radio is moving
away from the site or moving closer to the site. Moving away from the site causes the site becomes
less favorable to roam to, whereas moving closer causes the site becomes more favorable to roam to.
During searching, when the radio finds, synchronizes and validates successfully a candidate control
channel of a site, the radio starts registering with the site. Upon successful registration, the radio
completes the control channel acquisition process and starts monitoring the control channel at the new
site. Roaming can fail while validating or while registering, which causes the radio to continue site the
searching.
Roaming can also be triggered by failure conditions (for example, loss of control channel, site trunking,
repeater and network equipment) at the home site, or a manual site search request initiated by the
user. Roaming triggered by a manual site search request is called manual roaming. Manual roaming is
prevented when the radio is setting up a call.
1.16.5
Site Hunting
Hunting or searching site to attempt is done by stepping through all candidate control channels of a
site, and possibly all sites of the network by following the defined hunting sequences, which are short
hunting, long hunting, and comprehensive hunting. In each step the radio attempts to synchronize with
and validate the control channel, and if successful, register with the site.
Upon starting the hunting, radio performs short hunting, by stepping through the candidate control
channels of the home and adjacent sites, which are orderly listed based on their favorableness. Upon
exhausting this all site list, and if no candidatecontrol channel can be qualified successfully, the radio
repeats the short hunting four times, before it starts a long hunting sequence. During the long hunting,
the radio steps through the candidate control channels of the non-adjacent sites. The non-adjacent
sites are orderly listed as they appear in the site configuration. Upon exhausting this site list, and if no
control channel can be qualified successfully, the radio starts a comprehensive hunting sequence.
During the comprehensive hunting, the radio steps through the known frequencies based on the fixed
channel plan. The radio steps through the channel IDs that are convertible to an absolute frequency
through the fixed channel plan mapping. Comprehensive hunting is configurable, (i.e. can be enabled
or /disabled) only when the radio is configured for a Capacity Max Open System or Capacity Max
Advantage mode, otherwise comprehensive hunting is always disabled. The execution of the
comprehensive hunting is limited to 10 seconds. When it expires, because of no frequency can be
successfully qualified as a control channel, the radio suspends the comprehensive hunting and restarts
the hunting process from the short hunting.
The radio stays in an endless loop of the hunting sequences (short, long and comprehensive), as long
as no candidate control channel can be validated successfully. The radio enters an out-of-range state,
after attempting all the configured candidate control channels but none can be validated successfully.
An audiovisual indication is given to the user about the out-of-range state.
A commanded hunting is performed when the radio is commanded to go to a particular control
channel’s frequency. This feature is supported by the radio when working on an infrastructure that
54
MN003523A01-AC
supports DMR standard for commanded hunting. The Capacity Max infrastructure does not support
commanded hunting.
1.16.6
Control Channel Qualification
While hunting the candidate control channels, the radio attempts to qualify it. Qualification can be
successful which leads the radio to acquire and register with the site. If qualification fails, the radio
proceeds with the next candidate control channel of the same site or with the next site by following the
hunting sequence.
During qualification, the following information is validated within a limited time: signal strength, frame
synchronization, color code, slot and, DMR system parameters. If the time expires, and any validation
fails, the radio fails the candidate control channel.
1.16.7
Failure Handling
After successful registration, the radio starts monitoring the control channel to detect possible failures
such as loss of frame synchronization, detected invalid color code, or unmatched detected DMR
system parameters. These failures can cause communication with the home site, cannot be
maintained, and will trigger the radio to start searching a new home site.
When the communication between the home site control channel repeater and the trunking controller
fails, the home site enters a site trunking condition. A call cannot be repeated into or out of the home
site. A site trunking condition triggers the radio to attempt roaming.
When the radio is engaged in a call, it also monitors the payload channel used for the call. Failures
such as lost of frame synchronization can happen. When a failure occurs, the radio may drop the call
or perform a possible call handover to continue the call.
The radio remembers the site where it has experienced any failure, and will de-prioritize the site upon
site searching.
1.16.8
Call Handover
Capacity Max supports a proprietary call hand over, only for the radios that receive a voice, or are in a
call hangtime state in a voice talkgroup call. The transmitting radio does not support call handover. The
radio keeps transmitting, when the user with the transmitting radio, moves out of the home site
coverage. Upon dekey, the radio ends the call and performs site roaming.
The radio, which is engaged in a voice talkgroup call and works in Capacity Max Open System or
Capacity Max Advantage mode, can continue receiving the same call while roaming, with a reduced
minimal audio hole. This process is described below.
While in the call, the receiving radio periodically measures the signal strength of its payload channel
(the current payload channel). If the signal strength becomes lower than the RSSI Sampling Threshold,
the radio attempts to roam by starting to sample the adjacent payload channels that carry the same
call.
While attempting to roam, upon detecting that the signal conditions for a call handover are fulfilled, the
radio performs call handover. If not, the radio continues the call. There are two signal conditions that
must be fulfilled, the signal of the current payload channel is lower than the handover threshold value
and there is at least one adjacent payload channel that has signal strength more than 6dBm greater
than the current payload channel.
A failure in the current payload channel can initiate a call handover too, as long as the above
mentioned signal conditions are fulfilled. If not, the radio will drop the call and try to rejoin the call at the
same home site.
55
MN003523A01-AC
1.16.9
Manual Site Roam
Manual site roam is a way for the user to force the radio to start site searching, through a button
configured as Manual Site Search. Upon starting manual site roam, the radio leaves the home site and
searches the adjacent sites. Moving away from a site, user may not manually roam back to the original
site.
The radio may find any adjacent site, as long as the signal of its active control channel is above the
RSSI Acceptable Threshold, and the radio has not experienced any failure on the that site before.
Manual site roam does not cause the radio to register with an adjacent site that is less favorable than
the home site due to any failures. Upon manual site roam, the radio selects an adjacent site based on
the site preference level, the signal strength and whether the site is in a site trunking state or not.
Manual site roam is not intended to force the radio to lock to a particular site or register with a
particular site. It does not disable automatic roaming too. However, it is useful in combination with the
site-locked feature to allow the user to manually control roaming.
The radio prevents manual site roam when it is setting up a call, or when it is engaged in an individual
voice call.
1.16.10
Site Locked or Unlocked
Site-locked is a feature to prevent the radio from automatic roaming. Site-unlocked allows the radio to
roam automatically. A programmable button can be configured to have a Site Lock On or Off toggle
functionality.
When site-locked is switched on, the radio will not automatically roam from its home site, even though
communication with the home site cannot be maintained anymore, due to control channel failure or site
access failure, or even out of the home site coverage. If it happens, the radio will start site hunting by
stepping through all candidate control channels of the home site only, and never of the other sites. This
prevents the radio to roam to any other site automatically.
The only way to roam while being site-locked is through a manual site roaming. When the radio roams
manually to a new site, it remains in a site-locked condition, but with the new site. The user can further
start again manual site roam that causes the radio to roam to another site. After each roaming, the
radio remains in a site-locked condition with the respective site which the radio successfully registers
with. The user can control when to roam and when not to roam. from site to site, by doing this.
With Site Lock On or Off button, the user can switch off site-locked condition, which means the radio
becomes site-unlocked. The radio allows the automatic roaming back in effect, in site-unlocked.
A manual site roam, requested while the radio is site-unlocked, also causes the radio to leave the
home site and search for a new home site. The radio may land on a new site that has lower signal
strength or even less preferred than the home site, as long as the signal strength is acceptable and no
failure has been detected on that site. The radio remains in the new site for a period of time (that is, 2
minutes), and may eventually switches back to the previous home site when the time expires. This is
due to the automatic roaming which is still in effect and not prevented by the site-locked feature. An
activated site-locked feature can prevent the radio to roam back to the previous home site.
1.17
Capacity Max Radio Registration and Presence Notifier
This section describes the types of presence information provided by the Presence Notifier (PN) and
how third-party applications connect to the PN and obtain presence information of Capacity Max
56
MN003523A01-AC
radios. This section also describes configuration parameters in the PN and criteria for use of a
redundant PN.
The PN is a service that enables applications to obtain and track information about the presence of
radios. The Trunking Controller on the Capacity Max System Server (CMSS) implements the PN. The
trunking controller derives presence and mobility information for a radio from the over-the-air
registration by the radio and informs the third-party applications through the PN interface.
1.17.1
Connection of Third-Party Applications to Presence Notifier
The PN provides Transport Control Protocol (TCP) and User Datagram Protocol (UDP) interfaces to
third-party applications that require presence information for Capacity Max radios. Applications
subscribe for the presence information of radios from the PN, and the PN provides presence and
mobility information for the radios to the applications.
• The UDP interface provides one-time query functionality
• The TCP interface provides both one-time query and subscription functionalities.
1.17.2
Presence, Absence, and Mobility Information
The trunking controller derives the following types of information from the over-the-air registration.
Presence
A radio is present in a Capacity Max system when the radio is registered with the system. Registration
occurs on the following:
• On power-on
• On roaming to a site
• On changing the personality (that is knob position) from another system to the Capacity Max system
• On changing personality (that is knob position) having a different Tx talkgroup
• When the radio has not received a response for its request within the number of hours configured
as the Inactivity Check time.
Absence
A radio is absent in a Capacity Max system when the radio is not registered with the system. De-
registration occurs on the following:
• On power-off
• On changing the personality (that is, knob position) from the Capacity Max system to another
system
• When the system does not detect any activity from the radio within the number of hours configured
as the Inactivity Check time.
When powering off or changing personality, the radio sends a de-registration request over the air. In
the event of channel unavailability, lack of time, or poor coverage, de-registration may fail. Enabling or
disabling a radio in Subscriber Access Control (SAC) does not change the presence or absence state
of the radio.
57
MN003523A01-AC
Mobility
Mobility information of a radio means the RF site where the radio is present and registered. A mobility
change notification is sent by the PN to the application when a radio moves from one RF site to
another while registered with a radio network.
1.17.3
Subscription and Notification
When an application requires presence information for a radio, it submits a subscription request by
sending a subscription message to the PN. This message contains a dialogue identifier (Dialog ID),
which is generated and maintained by the subscribing application, as well as the device ID for a radio
or a range of device IDs for multiple radios. The PN identifies and maintains each subscription by using
the combination of the Dialog ID, the IP address, and the port number of the subscribing application.
The initial subscription message from an application to the PN establishes a “subscription dialog”
between the PN and the application. All subsequent communications associated with the same
subscription dialog is identified by the same dialog ID. The PN sends an immediate response to the
application upon receiving the subscription request. This response acknowledges the subscription
request and contains the current presence information of the requested entities in the subscription. As
the state or attributes of the presence entities change (for example, radio registration state changed
from present to absent), the PN generates notification messages and sends them to all applications
with accepted subscriptions for that entity.
The following table lists events that can be subscribed:
Table 5: Subscribed Events
Event Name Remarks

Present Application requests Present event
Absent Application requests Absent event
Mobility Event Application requests Mobility Update event
Present or absent events and mobility change events can be subscribed to in a single subscription.
An application can conduct a one-time query to fetch the current presence state of presence entities by
sending a request message with a new Dialog ID, and with an immediate expiration, that is, a duration
value of zero. The UDP interface is used mainly for sending a one-time query. The TCP interface is for
both one-time query and subscription.
The subscription persists for a period of time, or duration, that is specified in the initial subscribe
message. The subscription can be extended by sending a refresh subscription message with the same
Dialog ID prior to the scheduled expiration time. The PN deletes all subscriptions from an application if
its connection with the application breaks.
The application can cancel a subscription by sending a subscription message with the same Dialog ID
and a zero duration value. This causes an immediate termination of the subscription.
To monitor the health of the network connection to the PN, the application may periodically send a
keep-alive message to the PN. The keep-alive message is not associated with subscriptions and can
be sent at any time. The keep alive can be sent to the active or inactive PN.
58
MN003523A01-AC
1.17.4
Configuration Parameters for Presence Notifier
Table 7 shows configurable parameters for the Presence Notifier, that are programmed within the
Capacity Max System Server (CMSS) through the Radio Management application.
Table 6: Configurable Parameters for Presence Notifier

Configurable Parameters for Presence Noti-
Definition
fier
TCP port, UDP port Destination ports of Presence Notifier from ap-
plication point of view.
1.17.5
Presence Notifier Redundancy
An application can register for PN status to determine if the PN is active or inactive. The status of the
PN changes from inactive to active when the PN becomes ready to take subscriptions.
The application can register for PN Status with a primary and a secondary PN at the same time but
subscribes for radio presence only with the active PN.
• If both the primary and the secondary PN are active, the application should subscribe with the
primary PN.
• If the application loses connection with the primary PN and the status of secondary PN is active, the
application can subscribe with the secondary PN.
When switching back to the primary PN from the secondary PN, an application should cancel all its
subscriptions with the secondary PN.
1.18
Radio Access Restriction in Capacity Max System
This section describes the mechanisms to control access to a Capacity Max system by a radio, a Voice
Application, and a Data Gateway. It also provides their use cases and when a mechanism is more
effective than the others.
1.18.1
Mechanisms to Restrict Radio Access to Capacity Max System
Capacity Max provides three mechanisms to restrict a radio’s access. The mechanisms are as follows:
Authentication
The infrastructure authenticates a radio to ensure that the radio is what the radio claims to be. This
mechanism is useful to restrict the services of a Capacity Max system to only the radios that belong to
the system owner. Authentication prevents others from stealing the radio services. Authentication is
performed during every registration process of the radio. If the authentication fails, then the radio is not
registered. Therefore, any service request from the radio user is denied both by the radio and the
infrastructure. The required parameters for authentication are configured in the radios and the
repeaters by the Radio Management. See Authentication on page 60.
Subscriber Access Control (SAC)

Through its Radio Management, a Capacity Max system allows maintaining a list of permitted services
and a list of permitted sites for each radio in the system. When a radio sends a service request, the
59
MN003523A01-AC
infrastructure can deny the request if the service is not in the list of permitted services. Similarly, when
roaming to a site, the infrastructure does not register the radio if the site is not in the list of permitted
sites. SAC also allows to disable (and enable) all the services to a radio. SAC is useful for restricting
the services temporarily for a radio (for example, service is blocked due to non-payment of dues). The
SAC also allows the system owner to charge for services based on the type of services, number of
sites, or both. It can be utilized for dynamic changes the capabilities of a radio without reprogramming
the radio. See Subscriber Access Control on page 62.
NOTICE: SAC restrictions are only applicable to authenticated (or registered, if authentication is
disabled) radios. Without authentication, it is not very useful in preventing others from stealing
the radio services because the ID of a radio can be changed using Radio Management.
Stun/Revive
A Voice Application or radio (with the capability enabled in the SAC) can deny a radio the access to
services by sending an Over-The-Air command to the radio. A stunned radio does not request or
receive any user-initiated services on a Capacity Max system, where it was stunned. However, a
stunned radio does roam from one site to another, register, authenticate (if required), and execute a
received revive command. A stunned radio continues to send the location updates, receive location
request, and can be remotely monitored.
NOTICE: Stunning a radio on a system does not change the radio’s behavior on other system.
Stun is a system wide and not a radio wide.
Disabling a radio using SAC and stunning a radio has a very similar effect. The radio cannot initiate or
receive a call. The main advantage of Stun is that the radio continues to send location updates and
therefore a lost radio can be tracked. Another main advantage of Stun is the radio’s access to the
system is disabled immediately. The main disadvantage of Stun is that a radio can be stunned only if
the radio is powered on and is in coverage area of the system. See Stun/Revive on page 62.
Kill
Only a Voice Application can "Kill" a radio. A radio cannot initiate a request to kill another radio. “Radio
Kill” is intended to make the radio unusable when it is lost or stolen.
A killed radio disables all its functionalities across all its personalities except the the radio can be
powered on / off and over the wire, the radio accepts only those commands, which are essential for un-
killing the radio. This implies that a code-plug or firmware cannot be programmed into a killed radio.
While powered on, it indicates its “Killed” state.
In Killed state, the radio does not respond to the keypad, channel knob, or buttons. The radio does not
make over-the-air transmission and reception. A killed radio cannot be revived from the Kill state by
any over-the-air message. See Kill on page 63.
1.18.1.1
Authentication
This section describes the disadvantages of using the authentication feature, the use of a Mater Key in
Capacity Max to simplify Key Management when using the authentication mechanism, as well as the
use of enhanced version of the authentication process of the DMR Tier III standard in Capacity Max
system.
Authentication as an Optional Configuration Setting

The authentication of a radio by the infrastructure (during Registration or radio initiated Stun/Revive) or
the authentication of the infrastructure by a radio (during reception of a Stun/Revive) uses a “Challenge
and Response” process. A disadvantage of the process is that it requires additional Over-The-Air
messaging between the radio and the infrastructure. This reduces the inbound (for example, service
initiation) capacity of the control channel.
60
MN003523A01-AC
For this reason, Capacity Max has a configurable system-wide parameter to disable and enable the
authentication feature and a second slot registration. MOTOTRBO radios prefer to do registration (and
authentication) on the second slot of the control channel; and therefore, enabling authentication on a
Capacity Max system having MOTOTRBO radios do not reduce the service initiation capacity. It
reduces the registration capacity only.
User must configure the parameter in all Control channel-capable repeaters. Any change in the
parameter values is effective only after reprogramming all the control channel repeaters.
NOTICE: Reprogramming causes the repeater to reset.
Master Key for Simplified Key Management

Authentication relies on a 128-bit long key that is shared between an individual radio and the
infrastructure. If a same authentication key is programmed into each radio, then the compromise of one
radio affects the entire system. Alternatively, configuring a different key for each radio makes the key
management difficult. Therefore, Capacity Max uses a system-wide Master Key configured by the
system owner using Radio Management. The Radio Management derives a unique key for a radio
using a one-way function and provisions it into the radio, if the radio is a MOTOTRBO radio. For a non-
MOTOTRBO radio in a Capacity Max system, the key derived by the MOTOTRBO’s Radio
Management should be configured in the non-MOTOTRBO radio using its configuration tool.
The one-way function makes obtaining the Master key from a derived key difficult. The radio uses its
derived key to provide the response for the challenge during the authentication process. The
infrastructure calculates the unique derived key in the same way as the Radio Management, and uses
the derived key to verify the response received from the radio. The main advantage of the Master key
is that the owner and the system need to manage only one key for the authentication of all the radios.
The security of the “Authentication” rests in the key. Key management is the weakest part of the
security. It is easier to use flaws in people to obtain the key, than breaking the authentication algorithm.
Key value must be as random as possible, preferably generated by a reliable random source (including
rolling a die, roulette wheels, or lottery machines).
Physical Serial Number as Enhanced Authentication Mechanism

In a Capacity Max system, both the MOTOTRBO radio and the infrastructure use the Physical Serial
Number (PSN) of the radio to calculate the response for the challenge generated by the infrastructure.
This implies that an authentication is successful only if the radio has the right derived key and the
same PSN as configured by the system owner in the infrastructure.
Without the above enhancement, on the loss of a radio, the system owner can disable the radio in
SAC. Disabling the radio in SAC prevents someone from stealing the services using the lost radio.
However, disabling the radio prohibits the owner from re-using the ID of the lost radio, resulting in
Address Book changes in many radios.
This enhancement allows the system owner to replace the lost radio with another radio by replacing
the PSN of the lost radio with the PSN of the replacement radio.
NOTICE: The replacement radio is configured with the ID of the lost radio. If zero is configured
as the PSN for non-MOTOTRBO radios in the infrastructure, the enhancement is transparent
for non-MOTOTRBO radios.
61
MN003523A01-AC
1.18.1.2
Subscriber Access Control
This section describes the ways a system owner can control the services a radio can use in a Capacity
Max system.
A system owner can individually disable or enable the following services for each radio, Voice
Application and MNIS Data Gateways:
Table 7: Radio Services
Call Initiation Capability Call Reception Capability

Group Data Call Individual Voice Call
Individual Data Call Stun/Revive
Group Voice Call Kill
Broadcast Call Remote Monitor
Individual Voice Call Individual Telephone Call
System-wide Voice All Call
Multi-site Voice All Call
Site-wide Voice All Call
Telephone Call
Emergency Call
Remote Monitor
Short Data Call
Stun/Revive
Kill
Call Alert
Status Message
NOTICE: At least one Radio ID is associated with a Voice Application or a MNIS Data Gateway.
Not all the above listed capabilities are applicable to a Gateway. For example, a Gateway
cannot be stunned or a MNIS Data Gateway cannot use the voice services.
Capacity Max allows a System Owner to Control the Sites where a Radio can
Avail the Services
A Capacity Max system allows a radio to register only at the specified sites. Therefore, the radio can
initiate or receive a call at the specified sites only.
1.18.1.3
Stun/Revive
This section describes the Stun/Revive command supported in the Capacity Max system.
Only a Console/application connected to a gateway or a radio (with the capability enabled in the SAC)
can initiate Stun/Revive. Capacity Max infrastructure executes the Stun and Revive procedures on the
control channel. The target radio must be on the control channel and be within RF range for this action
to be completed successfully. The Capacity Max system supports Stun/Revive with or without
Authentication.
62
MN003523A01-AC
When Stun/Revive authentication option is enabled, on reception of Stun/Revive command, the

infrastructure authenticates the initiating radio and the target radio authenticates the infrastructure.
Authentication is supported in the system by sending a Challenge, receiving a response and validating
the response before executing the command. The authentication Key used for Stun/Revive of a radio is
the same Key used for the authentication of the radio during registration.
A radio is denied access to all user-initiated services for the system on which it was stunned. However,
roaming, registration, authentication, stun/revive services remain active. The radio can be remotely
monitored, and continues to send the location updates while stunned. The radio can also receive new
LRRP requests while stunned.
A radio can be revived by doing the following:
• Either sending (Over-The-Air) a “Revive” command to the radio
• Reprogramming the radio over USB connection using Radio Management
NOTICE: The radio cannot be revived by power cycling or by Over-The-Air Programming
(OTAP).
.
1.18.1.4
Kill
This section describes the Kill command supported in the Capacity Max system.
On receiving the Kill command, the radio always authenticates the network using the provisioned
Authentication Key. The same Authentication key is used for registration, Stun/Revive, and Kill.
Authentication is not optional for Kill and if an Authentication Key is not provisioned, then the default
Authentication Key is used. On successful authentication, the radio gets permanently disabled (Killed).
When a Killed radio is powered on, it provides an indication. From the indication, radio user/dealer can
easily know that the radio is killed.
A killed radio can be "unkilled" only by a depot's tool over the wireline. To "unkill" a radio the depot's
tool requires the same authentication key used to kill the radio.
NOTICE: The authentication key belongs to the owner of the radio. This means that only the
owner can un-kill a killed radio. This rule does not apply if the default Authentication Key is
used, therefore it is recomended to provision a Authentication Key when enabling Kill
functionality.
A radio's derived authentication key can be found in the Radio System View within Radio Management.
Over the wire, a killed radio acts only on those commands, which are essential for un-killing. This
means that a killed radio cannot be reprogrammed of reconfigured.
1.19
Capacity Max System Advisor
This section describes the architecture and features provided by the System Advisor. System Advisor
is a Capacity Max application that helps the system maintainers to manage their systems easily,
quickly diagnose the problems with the infrastructure devices and monitor the call activity in the
system, all from one centralized location.
Overview
The System Advisor is an application that provides fault management and system and call monitoring
solutions for Capacity Max Systems. It helps the system maintainers to manage their systems
providing centralized way to view the system health, detailed information about the status of the
infrastructure devices, perform simple operations on the devices remotely, and view the call activity
63
MN003523A01-AC
and the channel usage. The System Advisor manages infrastructure devices through several of
protocols, including SNMPv1, SNMPv3, ICMP and web-services.
The System Advisor consists of client and server application.
The server application runs on Capacity Max System Server (CMSS) logically located at the system
level (outside of RF sites). The system supports up to 5 System Advisor servers. When more than 2
System Advisor servers are deployed the TC selects 2 as active and the remaining servers as inactive.
The TC selects the System Advisor server on the CMSS that hosts the active TC and the System
Advisor server with the lowest device ID to be the active servers. An active System Advisor Server will:
• log system call activity
• display real time system traffic
• refresh information about managed devices
• log managed device's events and alarms
An inactive System Advisor server will log managed events and alarms of the device.
The client application is a Java Web Start application that can be run on Windows-based PC that has
access to the CMSS server (radio IP network). Client application requires Oracle Java to be installed
on the PC and a web browser. Systems with less than 2500 repeaters can support 10 System Advisor
Clients per System Advisor Server. Systems with more than 2500 repeaters can support 5 System
Advisor Clients per System Advisor Server.
The basic functionality of the System Advisor is enabled with the Capacity Max System Advisor
license. Optional functionality can be enabled through additional licenses.
The following are the main functions of the System Advisor:
1.19.1
System View
System View provides hierarchical view of System Advisor Network Database and groups the site level
devices under Site objects and system level devices under a System object. Status is propagated
upward from each device to provide an “at-a-glance” view of the system health. The user can quickly
navigate to the other views such as Alarm, Event or Network Database view, that show the additional
information for the selected element.
1.19.2
Real Time Call Monitoring
System Advisor provides two views that show real time call activities, as follows:
• Grid View
It shows the list of sites with available channels and the use of slot on the channels. User is able to see
the transmissions happening on the channels, call types, channel types, and fault state of the
channels, where it is fault state of the repeater hosting the channel.
• Raw View
It shows the list of calls and decoded events as received by System Advisor. View shows calls that are
in queue, active, ended, and the associated events. Other events which are not related to calls, are
also shown.
Both views provide simple customizing and filtering capabilities. Only active System Advisor servers
receive and display call activity information.
64
MN003523A01-AC
1.19.3
North Bound Interface
System Advisor receives events from the managed network devices, processes them, correlates
events to alarms and presents them to the operator. System Advisor additionally supports a North
Bound Interface (NBI) to send all these events to North Bound Managers like Network Management
Systems or Manager of Managers (this can be any Motorola Solutions or third party application
capable to receive and process System Advisor NBI notifications). The documentation that includes
specifications of the interface is provided by the Motorola Solutions ADP team. The interface includes
notification of network events and management events to the registered managers as follows:
• Network events
The network events are the events originated at the device level or the System Advisor regarding
certain network behavior. For example, if a network switch reports to the System Advisor that some of
its Ethernet port is down, such event will be sent to the registered NBI clients.
• Management events
The management events are events originated at the System Advisor as a result of management
operations performed on System Advisor like synchronization, discovery, manage / un-manage a
device, and others. For example, if the new device is discovered by the System Advisor, an event if the
discovery operation was successful is generated to the NBI clients.
The North Bound Interface supports both clear and secure capability of sending the notifications
(SNMP Traps) over SNMPv3 protocol. Its functionality requires North Bound Interface license to be
purchased by the customer. If the NBI license is purchased, up to two NBI destinations (managers) can
be registered using System Advisor client application.
1.19.4
Discovery and Network Database
Discovery is the process of adding an individual device or all the devices at a system into the System
Advisor database. System Advisor supports automatic triggering of discovery process for devices
reported by the system as well as manual discovery of the device after user provides necessary
parameters like the IP address and SNMP port.
In System Advisor application, the network database view serves as an inventory of the network
resources. It maintains the properties of all the managed resources, including both physical devices
(for example, the Repeater) and logical entities (for example, the Site, System, and Network) entities
discovered by System Advisor.
A user can invoke operations on inventory items such as command, manage / un-manage,
synchronization, ping, trace route, and others.
System Advisor manages and presents information about the following devices in Capacity Max
system:
• Repeaters
• Trunking Controllers
• Capacity Max System Servers
• System Advisors
• MNIS Voice and Radio Command Gateways (along with information about connected clients)
• MNIS Data Gateways (along with information about connected clients)
• Replicators
• Capacity Max Bridges
• Network Switches and Routers (MSI recommended)
65
MN003523A01-AC
• Manually discover other devices. System Advisor manages them, depending on how they are
recognized by the System Advisor and what management protocols they support.
1.19.5
Device Synchronization
Device Synchronization is defined as the basic mechanism that allows System Advisor to determine
and refresh information about the status of the managed devices. The synchronization process
performs periodic SNMP query on each device that is in “managed” state. Only active System Advisor
servers perform synchronization. If an alarm is dropped in the network, device synchronization
determines a alarm state of the device within 10 minutes. Inactive System Advisor servers do not
perform synchronization, so dropped alarms are lost. However, a user can initiate synchronization of a
selected device to obtain the current information about the device. When the user may not want to
receive updates about the state of some particular devices, the device may be moved by the user to
“un-managed” and synchronization process will omit such device.
1.19.6
Communication Link Management
Communication Link Management is defined as the basic mechanism for the System Advisor to detect
communication loss between itself and a particular managed device. Whenever a communication loss
is detected, the System Advisor will generate a communication loss alarm in the alarm browser. In
order for Communication Link Management to function, the device must be currently managed by
System Advisor..
1.19.7
Command Operation
The System Advisor provides command operation for repeater devices. The following commands are
supported:
• Enable, Disable, and Reset
Change the operational state of the repeater.
• Read of Repeater Remote Diagnostic counters
Gather the repeater diagnostic information and store it in log file for further analysis.
• Reset Repeater Remote Diagnostic counters
Reset the counters to initial value.
1.19.8
Network Events
Network event is the basic unit of management information that represents what has happened to a
particular managed device. Event can convey from general information such as discovery of a device,
to a specific type of information such as failure of a managed entity or status update of a managed
entity. Events form a repository of information for all the occurrences in the system. The System
Advisor event view provides a way to look at all events or a filtered subset of events, that are received
or generated by System Advisor.
User can view the details of each event, export them to cvs file or define custom views, to view a
filtered subset of events as well (for example, view only critical events that are from a particular device
type and / or from a certain site).
66
MN003523A01-AC
1.19.9
Alarms
In System Advisor, an alarm results from an event in a managed device that met a pre-determined
significant state change that may require user attention. The System Advisor alarm browser view
provides a way to look at all alarms, or a filtered subset of alarms. An audible tone can be associated
with alarms, based on severity.
An alarm becomes active once the System Advisor displays the alarm in the alarm view, without
clearing it. System Advisor will clear the alarm, whenever the problem that caused the alarm of a
particular managed device to be elevated in System Advisor is resolved. User with an administrator
privileges can set an Alarm Clear Timer policy, allowing the cleared alarms to persist in the System
Advisor alarm view, from 15 minutes to 10 hours, in 15 minutes increments.
The user can enter any additional information in a text field, and assign an alarm to a user. A user can
view the alarm details, export the alarms to csv file for future analysis and define custom views, to view
a filtered subset of alarms.
1.20
Capacity Max Radio Management
This section describes the devices in the system configured within Radio Management, the advantages
of centralizing all configurations, how the system parameters and device configuration sets simplifies
the configuration process, and the various configuration delivery options that Radio Management
supports.
Overview
Radio Management (RM) allows the administrator to configure, manage and program the subscribers
and infrastructure in a Capacity Max system. The following Capacity Max devices are configured with
Radio Management:
• Trunking Controller
• Repeaters
• Subscribers
• MNIS VRC Gateway
• MNIS Data Gateway
Radio Management is a required application for a Capacity Max system. It can be installed on any
computer that meets the minimum hardware and software requirements and that has a direct IP
connection to the Capacity Max system. The computer specifications are identified in another section.
Radio Management consists of a four major components that can be installed on the same or different
computers. The components include the Radio Management Server, the Radio Management Client,
the Radio Management Job Processor, and the Radio Management Device Programmer. The Radio
Management Job Processor is usually installed on the same computer as the Radio Management
Server.
The device configurations are saved centrally in the Radio Management Server, and can be accessed
remotely by the Radio Management Client. The Radio Management Device Programmer
communicates with the system and can be remote from the Radio Management Server to allow flexible
deployments. Reading and writing codeplug files with an unmanaged CPS is not supported in Capacity
Max.
67
MN003523A01-AC
1.20.1
Advantages of Radio Management
This section describes the advantages of Radio Management. The following are some advantages of
Radio Management:
Centrally Saved Configurations

Saving the configurations in the Radio Management Server allows all configurations to be centrally
managed. This removes the need to handle numerous codeplug files for every device in the system.
Centrally managing all the configurations in one database can:
• Simplify inventory by searching, sorting, and grouping radios in one place
• Simplify configuration by sharing device templates configuration sets and system parameter sets
• Simplify management of unique identifiers by cross referencing the configurations
System Level Configuration

All devices in a Capacity Max system reference the same system level parameters. This minimizes
entering duplicate information for each device type, therefore lowers the probability of mistakes.
Examples of system level parameters are trunking controller IP, site information, channel information,
and site adjacency information.
Subscriber Access Control

The subscriber access control (SAC) is configured within Radio Management. The SAC is where the
subscriber access to the system and the features allowed by that subscriber, are centrally controlled.
This information is programmed into the Trunking Controller.
Talkgroup to Site Association

The talkgroup to site is configured within Radio Management. The talkgroup to site association controls
which sites a talkgroup should always be routed to regardless of affiliation, and which sites a talkgroup
is specifically not allowed at. This information is programmed into the Trunking Controller.
Device Configuration Sets

Device Configuration sets can be shared across multiple devices of the same type, so that changes
are automatically applied to all devices using the shared configuration sets. This minimizes entering
duplicate information for each device, therefore lowers the probability of mistakes. This is most useful
for managing radio configurations of various groups within an organization.
Radio and Repeater Firmware Upgrades

Radio and repeater firmware are upgraded within Radio Management. The Trunking Controller, Voice
and Data Gateway, and System Advisor are not upgraded from within Radio Management. They utilize
a separate utility named ESU (Enhanced Software Updater).
Scheduled Batch Configurations

Numerous devices can be selected and their programming can be scheduled for a specific time. When
the scheduled devices become present after their scheduled time, their new programming is delivered.
This is extremely useful when programming numerous radios with different configuration sets and
unique identifiers.
68
MN003523A01-AC
1.20.2
Radio Management Programming Options
Radio Management provides numerous programming options, which include:
Direct USB Programming

Radio and repeaters can be programmed via a direct USB connection to the Radio Management
device programmer. This is required for the initial programming of these devices. Programming
includes configuration, firmware, feature activation, and device resources like the language packs,
voice packs, and others.
Over the IP Network Programming

The Trunking Controller, Voice Gateway, and System Advisor Server are configured via a direct IP
network connection with the Radio Management device programmer. After the initial programming,
repeaters are programmed over the IP network.
A Radio Management device programmer can be remote from the Radio Management server via a
direct IP network connection. Therefore, numerous device programmer computers can be strategically
located within the customer’s organization. The users need to plug their radios into a device
programmer computer via USB, and if previously scheduled will trigger the configuration to be
delivered and firmware to be upgraded.
Over the Air via Wi-Fi® Programming

Radio Management can program radios over Wi-Fi®. Programming includes configuration, firmware,
feature activation, and device resources like the language packs, voice packs, and others. Selected
radio models have Wi-Fi enabled from the factory. They are pre-configured with a default access point
profile (SSID and WPA/WPA2 passphrase).
When the radio initially powers up ‘out of the box’, it connects to an access point with the default SSID
and passphrase, and acquires an IP via DHCP. If a Radio Management device programmer is on the
same IP network, the radio becomes present to the device programmer. If there are any scheduled
jobs for the radio, they are delivered to the radio over Wi-Fi.
The radios are required to be added into Radio Management with their specific serial number, which
can be acquired from the invoice. A job should be scheduled, upon unique system identifiers, firmware,
device resources, and configuration sets are assigned.
Over the Air via the Radio System Programming

Radio Management can perform over the air programming on the radio system, once a Data Gateway
is configured and all subscribers are initially configured via USB or Wi-Fi and can communicate on the
radio system. When the devices scheduled become present on the system after their scheduled time,
their configurations are delivered. Since bandwidth is limited on the radio system, this process may
take a while. Firmware upgrade, feature activation, and device resources like language packs, voice
packs, and others are not supported over the air on the radio system.
When additional sites and channels are added, Radio Management can broadcast this information
over the air to the radios. The information is announced over the control channel of the existing sites
for a specified duration. This broadcasted method is quicker than individually scheduling each radio.
Over the Air via Bluetooth Programming

Radio Management can program radios over Bluetooth programming, which includes configuration,
firmware, feature activation, and device resources like (language packs, voice packs, and others.
Selected radio models have Bluetooth capability. The radio must be paired with the computer, where
the Radio Management device programmer resides. Programming over Bluetooth is best utilized when
69
MN003523A01-AC
other programming options are unavailable and access to the radio’s programming port is obscured.
This often happens, when programming a radio installed in-vehicle.
Off-Line Mode Programming

Radio Management can program radios, where the device programmer does not have an IP network
connection to the Radio Management server. This is often referred to as off-line mode. This is useful
when there is no IP network connectivity at the location, where the radios or repeaters reside. While
connected to the IP network, scheduled jobs can be selected and downloaded at the device
programmer. When disconnected, and the radios or repeaters become present (USB, Wi-Fi, and
others), the device programmer programs them. Once the device programmer is re-connected to the IP
network, it reports the device status back to the Radio Management server.
1.21
Radio Wi-Fi Support
Wi-Fi support, 802.11 b/g/n (2.4 GHz), for MOTOTRBO is a premium feature that is available on
selected devices.
Wi-Fi client operation, that is, the MOTOTRBO device connecting to a Wi-Fi access point, is supported.
MOTOTRBO devices do not currently support ad-hoc operation or access point operation (the
MOTOTRBO device performing as an access point for other devices).
1.21.1
Wi-Fi Network Name (SSID)
The SSID or network name need to match the SSID configured in the access point. The SSID is case-
sensitive and supports internationalization per the IEEE 802.11-2012 standard.
Hidden networks do not broadcast their SSID over Wi-Fi. Hidden networks are supported, but not
recommended, because it increases the connection time and does not protect against obtaining SSID
(SSID can still be obtained by other means).
1.21.2
Wi-Fi Security Support
The security setting should match the type of authentication and encryption used by your Wi-Fi router.
The security setting controls the access to the wireless network and the level of protection between the
MOTOTRBO device and access point.
• None provides no authentication or encryption. This security mode is supported but not
recommended.
• WEP is insecure and obsolete. This security mode is supported but not recommended.
• WPA/WPA2 Personal is supported with TKIP encryption.
NOTICE: WPS is not supported due to security flaws discovered in the protocol.
• “WPA/WPA2 Enterprise” is supported with TKIP encryption;

- Support EAP TLS
- Support PEAP with Phase 2 authentication as TLS and MSCHAPV2
- Support EAP TTLS with Phase 2 authentication as PAP, CHAP, MSCHAP, and MSCHAPV2
70
MN003523A01-AC
NOTICE:
In case the validation of the server certificate is required, the certificate of the subscriber and
the certificate of the authentication server must be issued by the same CA.
.
Access Point
RADIUS / Diameter
EAPOL
EAP
AP Authentication Server
E
Wi-Fi Clients
Networks
1.21.3
Wi-Fi Default Profile
MOTOTRBO devices that support Wi-Fi without an additional premium feature purchase include the
following default network. This supports an “out of box” configuration of the MOTOTRBO device via Wi-
Fi without requiring an initial programming of the Wi-Fi network parameters using a programming
cable. It is recommended to remove this network once the initial provisioning is completed.
Table 8: Wi-Fi Default Profile

SSID Security Type Network Passphrase
MOTOTRBO WPA Radio Management
1.21.4
Wi-Fi Channel Usage
The MOTOTRBO device supports the configuration of the regulatory region to meet the regulatory
requirements for frequency usage and power level for the Wi-Fi feature. The MOTOTRBO device also
supports configuration of the 802.11d protocol. If support for 802.11d protocol is enabled but no
802.11d broadcast is received, the MOTOTRBO device will use the regulatory region specified in the
MOTOTRBO device configuration.
NOTICE: As of January 1, 2015, the U.S. Federal Communications Commission (FCC) banned
the use of 802.11d within the U.S.
1.21.5
Wi-Fi Network Settings
The MOTOTRBO device supports Dynamic Host Configuration Protocol (DHCP) to obtain the network
settings from the Wi-Fi access point.
NOTICE: The MOTOTRBO device also supports static IP address assignment. The use of
DHCP is recommended in most cases because the IP network configuration typically varies
across different wireless networks.
71
MN003523A01-AC
1.21.6
Wi-Fi Network Protocols
The MOTOTRBO device supports configuration of Domain Name System Service Discovery (DNS-SD)
protocol using Multicast Domain Name System (mDNS). The MOTOTRBO device requires this feature
to be enabled to support some features on Wi-Fi and this information is detailed in the Wi-Fi feature
description. This protocol uses User Datagram Protocol (UDP) port 5353.
NOTICE: The use of Domain Name System Service Discovery (DNS-SD) protocol using
Multicast Domain Name System (mDNS) is also configurable for the Bluetooth and USB
network connections.
The average network bandwidth requirement, per device, is less than 50 bytes / second.
1.21.7
Radio Management
The MOTOTRBO radio management application supports all device configuration operations via the
Wi-Fi interface. The supported operations are the following:
• Configuration of Device Settings
• Update of Device Firmware
• Activation of Premium Features
• Updates of Device Resources (Language Packs and Voice Packs)
NOTICE: To determine which functionalities are supported, see the MOTOTRBO radio
management application release notes.
When the radio first powers up ‘out of the box’, it connects to an access point with the default SSID and
passphrase and acquires an IP via DHCP. If a Radio Management device programmer is on the same
IP network, the radio becomes present to the device programmer. If there are any scheduled jobs for
the radio, they are delivered to the radio over Wi-Fi.
This requires that the radios are already added into Radio Management with their specific serial
number, which can be acquired from the invoice. Unique system identifiers, firmware, device
resources, and configuration sets are assigned, and then a job should be scheduled.
The MOTOTRBO radio management device programmer component must be present on the same
local area network (LAN) as the MOTOTRBO device. This is required because the MOTOTRBO radio
management device programmer identifies MOTOTRBO devices using the DNS-SD protocol. The
deployment of a virtual local area network (VLAN) is beyond the scope of this document, but it provides
additional deployment options when physically deploying a MOTOTRBO radio management device
programmer on the same LAN is not feasible.
72
MN003523A01-AC
1.21.8
Recommended First Time Work Flow
The following diagram depicts the recommended first time work flow.
Figure 1: Recommended First Time Work Flow
1.22
Certificate Management
Certificate management provides a solution for managing certificates in the MOTORBO system.
1.22.1
Certificate Management Feature Overview
The MOTOTRBO device supports Certificate Management through the Simple Certificate Enrollment
Protocol (SCEP).
The following certificate management operations are supported:
• Supports RSA based X.509 V3 certificate.
• Supports downloading Certificate Authority (CA) certificate.
• Supports client certificate enrollment and auto-renewal.
• Uses Challenge Password to authenticate the radio as the valid SCEP client.
• Uses MD5 Fingerprint to validate the CA certificate.
• Supports RSA key size as 1024, 2048 and 4096 bits.
• Supports Signature Hash Algorithm as MD5, SHA-1, SHA-256, SHA-384 and SHA-512.
NOTICE: Certificates are used for Wi-Fi Enterprise.
73
MN003523A01-AC
1.22.2
Certificate Enrollment
This section describes the certificate enrollment process.
1 Network Administrator receives a challenge password from the Simple Certificate Enrollment
Protocol (SCEP) server.
2 Network Administrator passes the challenge password and other enrollment data to a Fleet
Manager.
3 Fleet Manager loads the challenge password and other enrollment data to radio through RM and
associates it with the Enterprise SSID.
4 Fleet Manager programs an enrollment access point and SCEP server location into the radio.
5 The radio initiates enrollment through enrollment access point (WPA/WPA2 Personal).
Figure 2: Certificate Enrollment
Certificate
Enrollment Access Point SCEP Server
Authority
WPA/WPA2 Personal Network
NTP Server
SCEP Enrollment
Wi-Fi Clients
Networks
1.22.3
Certificate Renewal and Rollover
The radio initiates the renewal process based on a configurable timer called the Renewal Period. The
Renewal Period shows the period that triggers a renewal. For example, the value of 30 days means
that the radio triggers the certificate renewal 30 days before the certificate expires.
The radio must be on a network with access to Network Time Protocol (NTP) and Simple Certificate
Enrollment Protocol (SCEP) to renew the certificate. Rollover or Certificate Authority (CA) Renewal is
also supported.
Figure 3: Certificate Renewal and Rollover
WPA/WPA2 Certificate
SCEP Server
Enterprise Wi-Fi Authority
Network
NTP Server
SCEP Renewal
SCEP Rollover
Wi-Fi Clients
Networks
74
MN003523A01-AC
1.22.4
Design Considerations
When designing your certificate management system, you must follow these general guidelines.
• The certificate enrollment, renewal, and rollover processes take one to five minutes to complete
each. The duration of these processes depend on the key size and network conditions.
• Configure the renewal period of the Certificate Authority (CA) certificate longer than that of the client
certificate, so that the renewed CA certificate is available for the client certificate renewal.
• You can leverage the key usage extension for the following two purposes:
- To single out the Registration Authority (RA) certificate. The key usage of the RA certificate must
contain at least a digitalSignature and must not contain keyCertSign & cRLSign.
- To single out the encryption certificate. If a separate certificate is deployed at the Public Key
Infrastructure (PKI) to decrypt the Simple Certificate Enrollment Protocol (SCEP) data from the
radio, the key usage of the certificate must contain keyEncipherment only. Certificate
Enrollment Protocol (CEP) encryption certificate by Microsoft Network Device Enrollment
Service (NDES) is an example.
• Ensure that the subscriber has good coverage in the Wi-Fi network so that the PKI can be accessed
during the renewal and rollover period. You must re-enroll the certificate if the renewal or rollover
process cannot be completed before the certificate expires.
1.23
Radio Bluetooth Support
The MOTOTRBO radio subscriber supports the Bluetooth Headset Profile (HSP), Bluetooth Personal
Area Networking (PAN) profile for Bluetooth IP networking to a PC, and Serial Port Profile (SPP) for
communication with Commercial Off-the-Shelf (COTS) Bluetooth Headset, Bluetooth Barcode
Scanner, Motorola Solutions Bluetooth Headset with remote PTT, and Motorola Solutions Bluetooth
PTT Only Device (POD). The radio subscriber supports up to four simultaneous Bluetooth device
connections, one of each type. The types include HSP, SPP, PAN and Fast PTT.
NOTICE: The radio subscriber can connect to a Bluetooth headset, a Bluetooth scanner, a
Bluetooth PAN PC and a Motorola Solutions Bluetooth POD simultaneously.
1.23.1
Bluetooth Pairing and Connection
Bluetooth operates within a range of 10 metres line-of-sight. This is an unobstructed path between the
radio and the Bluetooth device. It is not recommended to leave the radio unattended. At the fringe
areas of reception, both voice and tone quality may start to sound “garbled” or “broken”. To correct this
problem, simply place the radio and headset closer to each other.
For pairing with multiple Bluetooth devices, it is recommended to pair with data devices such as the
scanner and/or Motorola Solutions POD, before the headset. If the headset is paired first and activates
the audio link, the audio link delays and/or interferes with subsequent pairings between the radio and
additional Bluetooth devices. In some scenarios, pairing to additional devices may time out and fail due
to audio link interferences, requiring attempts for reconnection. Hence pairing with data devices prior to
the headset provides a better pairing experience. In order to allow other Bluetooth devices such as the
PC to discover and pair with the radio, place the radio in Bluetooth “Find Me” mode. The radio can
enter this mode through the user menu in the display model, or via a programmable button on the non-
display model.
75
MN003523A01-AC
Pairing a Bluetooth Device with Display Radios

Pairing a device with a display radio is initiated by the user. Turn on the Bluetooth device and place it
in pairing mode. To locate available devices, use the Find Devices option under the Bluetooth menu.
Some devices may require additional steps to complete the pairing. Refer to the respective devices’
user manuals. Upon successful pairing, the radio display and tone indicators will alert the user of an
established connection.
NOTICE: If the Bluetooth device requires pin authentication, the user will be prompted to enter
the pin code via the keypad, to establish a connection.
Pairing a Bluetooth Device with Non-Display Radios

Pairing a device with a display radio is initiated by the user. Turn on the Bluetooth device and place it
in pairing mode. Use the preprogrammed Bluetooth button on the radio to connect to the device. The
LED blinks yellow and a tone sounds when a connection is being established. Upon successful pairing,
a positive tone will alert the user of an established connection.
NOTICE: If pin authentication is required for pairing, the pin codes should be preprogrammed
into the nondisplay radios via RM.
1.23.2
Bluetooth Headset/PTT and Radio Operation
Radio Operation with COTS Headset

When the radio and COTS headset are paired and connected via user selection through the display
radio user interface, the radio sends ring indications to the headset to indicate the start of an incoming
audio call setup. The incoming call can be accepted by pressing the multi-function button on the
headset; the audio link is set up between the radio and headset for communication. Once the Bluetooth
audio link is connected, the Bluetooth microphone/speaker is used as the active audio path for voice
communication. When the radio receives an incoming voice transmission, the incoming audio is routed
to the Bluetooth headset speaker. When the radio PTT is pressed, the radio initiates an outgoing voice
transmission with the headset microphone audio. The radio treats the headset microphone audio
similar to the internal radio microphone audio for outgoing call transmissions.
For portable radios, the active Bluetooth audio path can be switched on/off from the radio user
interface via menu, or programmable button. For mobile radios, the active Bluetooth audio path can be
switched on/off via the on/off hook.
The audio path automatically switches from the Bluetooth headset to the radio when the headset
disconnects either intentionally or accidentally, or when the headset battery is dead. Otherwise, the
user can manually press the multi-function key of the COTS headset to switch to the radio audio path.
Radio Operation with Motorola Solutions Headset/PTT

For Motorola Solutions Bluetooth headsets equipped with a remote PTT, the remote PTT can be used
to initiate outgoing voice transmissions. The audio path will be set up to the headset audio path after
the connection to the headset/PTT is established.
Radio Operation with Motorola Solutions PTT Only Device (POD)

The radio also supports the Motorola Solutions Bluetooth POD for initiating voice communication. This
device can be connected and used independently with the radio, or could also be used in conjunction
with a Bluetooth headset connected to the radio. The remote POD is used to initiate outgoing voice
transmissions. Pressing the POD works the same as pressing the radio PTT button with respect to
audio transmission and routing.
76
MN003523A01-AC
This device is not equipped with a local microphone or speaker; the Bluetooth headset or radio
microphone/speaker will be used for audio communication.
1.23.3
Bluetooth Barcode Scanner Operation
After the radio and a Bluetooth barcode scanner are paired and connected as a SPP serial device via
user selection through the radio user interface, the scanned data sent from the scanner to the radio
could be routed to the option board or to a remote radio via the over-the-air interface. The routing of
the data to the option board or to the remote radio is configurable via RM. Sending the data from the
radio via the over-the-air interface to the remote radio is supported in digital mode only. The security
support for over-the-air interface transmission is limited to the radio’s Enhanced Privacy support.
Routing of data from the radio to the option board is supported in both analog and digital mode.
1.23.4
Bluetooth Personal Area Networking (PAN) Operation
The radio supports the Bluetooth PAN as an access point. The remote Bluetooth PAN device, for
example a PC should be connected to the radio as a PAN client. After the radio and the remote
Bluetooth PC client are paired and connected with the PAN profile, an IP network connection will be
established for IP datagram communication. All data communication between the radio and Bluetooth
PC client should be addressable with IP address and application port number over the Bluetooth PAN
connection. If a large amount of data needs to be communicated between the radio and the PC
application, it is recommended to disconnect any Bluetooth headsets and other Bluetooth devices from
the radio. The PAN connection data communication can slow down greatly if any devices of other
Bluetooth profiles are connected.
1.23.5
Recommended Bluetooth Devices
NOTICE: It is not recommended to use any Bluetooth device which is not listed in this page.
Below is a table of COTS Bluetooth devices (headset, PTT and scanner) recommended by Motorola
Solutions for use with MOTOTRBO radios. Only these Bluetooth devices have been tested, validated
and qualified for many quality attributes such as audio, size, weight, comfort, battery life, and
interoperability. This table may change in the future to include more devices.
The following are key considerations when selecting a device:
1 A Bluetooth device with enhanced audio processing
2 A headset that supports disconnecting/reconnecting the active audio link to the radio by pressing/
releasing the multi-function button. This maximizes headset battery life.
Table 9: COTS Bluetooth Devices Recommended by Motorola Solutions
Model Description
89409N Motorola Solutions HK200 Operations Critical Wireless, 128-bit Encryption,
Commercial Secure Simple Pairing (SSP) version 2.1
NNTN8125 Motorola Solutions Bluetooth Wireless Accessory Kit, STD Pairing, 12" Ca-
ble
NTN2572 Motorola Solutions Bluetooth Accessory Earpiece with 12" Cable
NNTN8143 Motorola Solutions Bluetooth Wireless Accessory Kit, STD Pairing
77
MN003523A01-AC
Model Description
NNTN8126 Motorola Solutions Bluetooth Wireless Accessory Kit, STD Pairing, 9.5" Ca-
ble
NTN2575 Motorola Solutions Bluetooth Accessory Earpiece with 9.5" Cable
Symbol CS3070 COTS Symbol Barcode Scanner
1.23.6
Avoiding Accidental Connection
The Bluetooth headset is usually assigned to one person. However, the two-way radio may not be
assigned to a person; it could be shared by different people such as retail sales associates,
housekeeping, security and others. If a Bluetooth headset was paired with a radio, the headset
automatically reconnects to the same radio the next time it powers on.
Scenario: If the same radio has been assigned to a different user, the headset can accidentally
reconnect to the wrong radio belonging to a different user. Automatically, the previous user still
receives a positive pairing indication from the headset. To avoid accidental connection as described in
the above mentioned scenario, follow the instructions below:
• For HK200: Erase all pairing information from the headset by pressing and holding the volume
button and call button together, followed by turning on the headset. When this procedure is
performed, the headset does not initiate connection to any remote device automatically.
• For Motorola Solutions Headset/PTT and POD: Erase all pairing information from the device by
pressing and holding the PTT button followed by turning on the headset. When this procedure is
performed, the headset or POD does not initiate connection to any remote device automatically.
1.24
Over The Air Battery Management
The proprietary IMPRES™ Battery Fleet Management technology is used to manage radio batteries
and chargers, regardless of where they are located.
1.24.1
Over The Air Battery Management Overview
IMPRES Battery Fleet Management enables collection of battery information each time an IMPRES
battery is inserted into an IMPRES charger. It also enables automatic collection of battery information
over the air while the radios are in use. This removes the need for wired network connections, Charger
Interface Units, and remote clients at charger locations.
With IMPRES Battery Fleet Management, existing or customizable reports can be utilized to see the
most relevant information. Data is stored in a database and can be exported to an xls file or printed.
IMPRES Battery Fleet Management software records and organizes a variety of data so the user can:
• Evaluate whether batteries are meeting their performance criteria
• Determine when batteries are nearing their end-of-life
• Eliminate unexpected downtime and work interruptions
• Avoid the expense of throwing batteries away prematurely
• Identify batteries that are missing, misplaced or inactive
• Identify radios that are not using IMPRES batteries
• Decide exactly when to buy new batteries
• Optimize charger utilization
78
MN003523A01-AC
NOTICE:
Over the air battery management focuses on managing the long term health of the batteries. It
is not meant to acquire the current real-time energy levels of all radios within the system.
Collection of battery information over the air is supported in the following radio series when they are
utilizing IMPRES batteries:
• XPR7580
• XPR7550
• XPR7380
• XPR7350
• XPR3500
• XPR3300
For Battery Management computer specifications, see "Capacity Max Hardware Specifications" in
Capacity Max Installation and Configuration manual.
1.24.2
Over The Air Battery Management Theory of Operations
The Battery Fleet Management application (BMA) communicates with the radio system through an IP
data gateway. The IP data gateway can be either the Motorola Network Interface Service (MNIS),
which communicates via IP to the repeaters in the system, or a mobile radio configured as a control
station.
The Battery Fleet Management application (BMA) starts empty. Within a few hours after a radio powers
up, it registers its current battery over the air with the BMA. If the battery has never been registered
with the BMA before, the BMA creates a new record for the battery and reads its battery data over the
air. If the battery has been registered with the BMA before, the BMA checks the last time the battery’s
data was read. If it has not been recently read, the BMA reads the battery data over the air. If it has
been recently read, no action is taken. Radios register their battery about once a day, and a battery’s
data is read once every few weeks.
For more information, see "Over The Air Battery Management Configuration" in Capacity Max
Installation and Configuration manual.
1.25
Capacity Max Priority Monitor
This section describes the Priority Monitor feature, which helps to monitor radio talkgroup priority
1.25.1
Priority Monitor Feature Description
The Priority Monitor feature is supported in both Open System and Advantage modes. It allows a radio
that is listening to a voice talkgroup call to leave the current call and join a higher priority voice
talkgroup call on another channel. The level of priority from highest to lowest in a radio is:
• Priority 1 emergency talkgroup call
• Priority 2 emergency talkgroup call
• Emergency talkgroup call
• All Call (Site, Multi-site, and System)
• Priority 1 talkgroup call
• Priority 2 talkgroup call
79
MN003523A01-AC
• Talkgroup call
A radio automatically affiliates to its priority talkgroups. This allows routing of priority talkgroup calls to
the required sites. Routing increases the probability of receiving priority talkgroup calls when roaming
to sites where the priority talkgroup is not present. When a priority talkgroup call occurs at a site, the
active repeaters broadcast priority talkgroup information to the radios. While listening to a talkgroup
call, a radio monitors the priority talkgroup broadcasts and automatically leaves to join higher priority
calls.
The time to broadcast a single priority talkgroup can be optimized if all priority talkgroup IDs are less
than or equal to 1020. Optimizing the single priority talkgroup broadcast time reduces the time for a
radio to join and unmute to a higher priority talkgroup call.
The priority talkgroups reside in the Digital RX Group List. If a user disables Scan, the RX Group List is
no longer utilized and therefore priority talkgroups will not be received.
1.25.2
Configuration in the Capacity Max System Server (CMSS)
Any talkgroup can be configured as a priority talkgroup in the system. If a talkgroup is configured in at
least one radio in the system, then the talkgroup must be configured in the system as a priority
talkgroup. It is this configuration that enables the repeaters to broadcast priority talkgroup information
while transmitting.
A talkgroup is set as a Priority Monitor talkgroup within the Talkgroup Site Association in the Capacity
Max System Server Data within Radio Management. The Priority Monitor checkbox must be selected
for the talkgroup that is to be Priority Monitored.
1.25.3
Configuration in the Capacity Max Radio
Priority 1 and Priority 2 talkgroups are configured in a radio's RX Group List and the radio may be
configured to allow the user to have priority talkgroup edit rights. When given priority talkgroup edit
rights, the radio user can remove or add priority status to a talkgroup in the RX Group List. If the user
adds a priority talkgroup that is not configured in the system, the priority monitor feature will not work
for that talkgroup. For more details on configuring the RX Group List, see Capacity Max RX Group List
and Scan on page 83.
1.26
Capacity Max Talkgroup Affiliation List
A Capacity Max radio may be configured to affiliate up to seven talkgroups at a site. These talkgroups
are the selected talkgroup and any of the talkgroups residing in the RX Group List, which includes the
Priority talkgroups. The radio automatically affiliates to the selected and any priority talkgroups. Other
talkgroups in the RX Group List may be configured for affilaition as well. The automatic affiliation of
priority talkgroups as well as any configured non-priority talkgroups improves the probability of
receiving these talkgroups because the radio no longer requires another radio to be affiliated with the
non-selected talkgroups at that site.
The Capacity Max system allows a radio to be registered on the system even when some or none of
the talkgroups in the affilaition list are successfully affiliated at the site. If the selected talkgroup or a
priority talkgroup is not successfully affiliated because the talkgroup is not allowed at the site, the
background behind the selected talkgroup alias on the home screen is red. This allows the user to
easily see that one of their main talkgroups has not successfully affiliated at the site.
A user may view the current affiliation status of the RX Group List talkgroups when registered at a site.
This is accomplished by viewing the Scan List.
80
MN003523A01-AC
• A green check mark to the right of the talkgroup alias indicates the talkgroup has successfully
affiliated at the current site.
• A black dot to the right of the talkgroup alias indicates the talkgroup is selected for affiliation but the
affiliation was unsuccessful at the current site.
• No indication to the right of the talkgroup alias indicates the talkgroup is not selected for affiliation.
1.26.1
Affiliation List Configuration in the Capacity Max Radio
A talkgroup may be selected for affilaition in the RX Group List. Additionally, the radio may be
configured to allow the user to edit the Scan List. When enabled, the user can add and delete affiliation
talkgroups. Only talkgroups already configured in the radio may be added by the user. The user can
also select or deselect a talkgroup in the Scan List for site affiliation if they have edit rights.
1.26.2
Loading Impacts of Talkgroup Affiliation List
When radio users are allowed to affiliate more than one talkgroup with the system, it is important to
make sure that enough system resources are available to support the extra load. There are two system
performance parameters that are impacted: The maximum inbound registration rate (rph) and the
number of sites per call (sites/PTT).
The Impact of Multiple Talkgroup Affiliation on the Maximum Inbound

Registration Rate
The maximum inbound registration rate (rph) lowers as more radio users affiliate to more talkgroups
(i.e. scan). Because a registration with multiple affiliations utilizes more bandwidth on the control
channel, fewer registrations can be made per hour. for more details on the impact to the inbound
registration limit, see Number of Trunking Repeaters Selection in Capacity Max on page 132.
The Impact of Multiple Talkgroup Affiliation on the Number of Sites per Call
The average number of sites per call (sites/PTT) may increase as more radio users affiliate to more
talkgroups (i.e. scan). As the number of users affiliated to a talkgroup increases, the number of sites
that need to be included in a call to service those users may need to increase. An increase to the sites
per call may increase the number of repeaters needed at each site to support the calls initiated at the
other sites. For more details on how multiple talkgroup affiliation (i.e. scanning) impacts the number of
sites per call, see Number of Users and Usage Prediction on page 122.
1.27
Capacity Max and WAVE5000
This section provides a very general overview of the features that WAVE5000 supports in Capacity
Max. Detailed information can be found in the WAVE5000 system planner.
1.27.1
Capacity Max and WAVE5000 Overview
The WAVE5000 server supports PTT voice communications among broadband network (cellular, WIFI,
and others) devices as well as between broadband network devices and MOTOTRBO Capacity Max
radios. The solution includes the following components:
WAVE5000 Server
The WAVE5000 Server communciates to the Capacity Max system via the MNIS VRC Gateway. A
maximum of one WAVE 5000 Server is supported per system. The WAVE5000 Server supports up
81
MN003523A01-AC
to 50 simultaneous calls. A group call that includes multiple broadband devices is considered one
call since IP multicasting is utilized.
WAVE Mobile Communicator Client
The WAVE Mobile Communicator client is installed on a broadband device. The maximum active
Mobile Communicator client users per Capacity Max system is 3000.
1.27.2
Supported Capacity Max Features
The Capacity Max WAVE5000 solution supports the following DMR voice call types:
• Group Call
• All Call (Site, Multi-Site and System)
• Individual OACSU Call
The Capacity Max system must be configured for OACSU individual voice calls when WAVE5000
solution is deployed. WAVE5000 does not support FOACSU individual voice calls.
WAVE5000 supports Enhanced Privacy for Group Calls, All Calls and OACSU Individual Calls.
1.27.3
Connection into Capacity Max System
The WAVE5000 Server resides on the Capacity Max IP network. For more details on the
recommended network and IP address, see "Understanding IP Addressing" in the Capacity Max
Installation and Configuration Manual manual.
The default network switch configurations have provided a port for the WAVE5000 server. For more
details, see "Configuring a Capacity Max System Transport Network" in the Capacity Max Installation
and Configuration Manual manual.
The WAVE 5000 server connects into a Capacity Max system through a MNIS VRC Gateway. Calls
that include WAVE5000 clients require VRC Talkpath licenses. For more details, see "MNIS VRC
Gateway Configuration" in the Capacity Max Installation and Configuration Manual manual. For
guidance on selecting the appropriate number of VRC Gateway talkpaths, see Number of VRC
Gateways and Talkpaths Selection on page 145.
The radio IDs utilized by the WAVE Mobile Communicator Clients must be entered into the Subscriber
Access Control (SAC) in order to be allowed on the Capacity Max system. For more details, see Radio
Access Restriction in Capacity Max System on page 59 and "System Parameter Configuration" in the
Capacity Max Installation and Configuration Manual manual.
1.28
Capacity Max Status Message
This section describes the Status Message functionality.
1.28.1
Status Message Feature Description
A Status Message uses the mapping of a pre-configured status text string to a decimal status ID, for
example decimal status ID 25 means “Material Delivered, Returning to Home Base”. The mapping
should be the same in the endpoints (source and destination/s). Here, the endpoints can be radios,
talkgroups, and 3rd party console applications. The Status Message ID is sent as a single burst on the
control channel. Status Message is more spectrally efficient than an actual text message because
there is no payload channel allocation and the message is compact. Though more spectrally efficient,
the preconfiguration to map a message into a number is not as flexible as an actual text messaging.
82
MN003523A01-AC
1.28.2
Configuration in the Capacity Max System Server
The Status Message feature allows transmission of a Status Message from a radio, or wireless/wireline
console to a radio, Talkgroup, or wireless/wireline console. It is a feature specified in ETSI DMR Tier 3.
The Status Message feature has to be enabled for the initiating radio ID in the Subscriber Access
Control (SAC) of the Capacity Max System Server (CMSS). Reception is not restricted and occurs
automatically.
1.28.3
A radio supports up to 100 preconfigured Status Messages per Capacity Max system. Both endpoints
(source and destination) must be configured with the same decimal status ID to pre-configured status
text string.
A Capacity Max Status List is configured in the System Parameter Set within Radio Management. A
system can contain multiple Capacity Max Status Lists. For more details, see the "System Parameter
Configuration" in the Capacity Max Installation and Configuration manual.
A radio configuration references the Capacity Max Status List created in the System Parameter Set. In
addition, the Capacity Max Status List must be selected in the Site Selection List utilized by the Radio
Configuration. For more details, see the "Trunking Subscriber Configuration" in the Capacity Max
One Touch Access configuration is performed in the Control Buttons settings in a Radio Configuration
within Radio Management. The following should be set:
• One Touch Access Mode is set to Capacity Max,
• Call is set to the Target Radio or Talkgroup from the Contact list
• Call Type is set to Status
• Capacity Max Status List is set to the previously defined Capacity Max Status List, and
• Capacity Max Status is set to the desired status within the Capacity Max Status List.
The configured One Touch Access can then be assigned to a button on the radio.
1.28.4
Status List and Status Message Initiation
Access to the Status List occurs through a one touch button and front panel menu. The Status List
contains received Status Messages as well as the last transmitted Status message. A user may delete
received Status Messages from the Status List. Upon reception of Status Message decimal ID without
a corresponding pre-configured status text string, the Status List only displays the decimal ID.
A radio user may initiate the transmission of a pre-configured Status Message via a one touch button.
From the Status List the radio user may respond with a Status Message or with an individual call to the
source radio.
1.29
Capacity Max RX Group List and Scan
This section describes RX Group List and Scan feature.
83
MN003523A01-AC
1.29.1
RX Group List Description
A radio personality may include a RX Group List that contains a list of up to 16 talkgroups. The radio
unmutes to any talkgroup in its RX Group List. To disable a radio from unmuting to talkgroups in its RX
Group List, scan must be disabled. To support backwards compatibility, scan is enabled by default. Of
the 16 talkgroups in the RX Group List one can be Priority 1, another can be Priority 2 and the others
are non-priority talkgroups. A radio involved in a non-priority call will leave and join a priority call.
A radio can affiliate up to 7 of the 16 RX Group List talkgroups upon power on, site change or channel
change. Any priority talkgroup is automatically affiliated along with the selected talkgroup. The
automatic affiliation of priority talkgroups, as well as any configured non-priority talkgroups, improves
the probability of receiving these talkgroups because the radio no longer requires another radio to be
affiliated with that talkgroup at that site.
1.29.2
Front Panel Scan List
The radio user can view the RX Group List from the front panel menu as the Scan List. The Scan List
indicates:
• whether a talkgroup is a priority talkgroup
• whether a talkgroup is selected to affiliate
• whether or not the affiliation was successful at the current site
A "P1" or "P2" to the left side of the talkgroup alias indicates the talkgroup is a Priority 1 or Priority 2
talkgroup respectively. Indications to the right of the talkgroup alias have the following meaning:
• A green check mark: the talkgroup has successfully affiliated at the current site
• A black dot: the talkgroup is configured for affiliation but the affiliation was unsuccessful at the
current site
• No indication: the talkgroup is not configured for affiliation
1.29.3
The following parameters are available in the Radio Configuration with in Radio Management.
Digital RX Group List

Up to 16 talkgroups can be assigned to a radio personality in the Digital RX Group List. Of these 16
talkgroups:
• one can be assigned as Priority 1
• one can be assigned as Priority 2
• up to 7 talkgroups can be assigned as affiliation talkgroups
The selected talkgroup and the priority talkgroups are automatically affiliated. Therefore, in the
situation where a radio is configured with a selected talkgroup and a Priority 1 talkgroup, up to 5 non-
priority talkgroups can be configured for affiliation.
RX Group List Editing via Menu

The radio can be configured to allow the user to edit the RX Group List from the front panel menu. Edit
rights include:
• adding or removing priorities from talkgroups
84
MN003523A01-AC
• adding or removing talkgroups from the list

• selecting or deselecting, if the talkgroup affiliates
Only talkgroups already configured in the radio may be added to the RX Group List. Additionally, the
user is able to replace the curerent RX Group List that is associated with the selected talkgroup with
another RX Group List that resides in the radio.
Talkback
The radios can be configured to enable or disable talkback. When talkback is disabled and the radio
user presses PTT while participating in a talkgroup call from the RX Group List, the radio leaves the
call and initiates a call to the selected talkgroup. When talkback is enabled and the radio user presses
PTT while participating in a talkgroup call from the RX group list, the radio remains in the call and
attempts a transmission for the current talkgroup call. Regardless of talkback setting, when the radio
user presses PTT while participating in the selected talkgroup call, the radio remains in the call and
attempts a transmission for the selected talkgroup call.
Talkgroup Scan Hangtime

The radio also contains a configurable Talkgroup Scan Hangtime value. The default is 1.5 seconds.
This hangtime is applied when a radio leaves a priority call to initiate a new call to another talkgroup.
The typical scenario occurs when talkback is disabled and the new call is made to the selected
talkgroup. After the new call ends, the radio returns to the control channel and initiates Talkgroup Scan
Hangtime. At the expiration of Talkgroup Scan Hangtime, the radio joins the highest priority call
received during the hangtime period. Increasing the Scan Hangtime value increases the probability of
the radio joining the highest priority call but also increases the time to join any call under this scenario.
An increase in the time to join a call typically leads to an increased audio truncation time.
Enable/Disable Scan via Programmable Button

The radio can be configured to allow the user to enable/disable scan with a programmable button or
through the front panel menu. When scan is enabled the radio unmutes to the selected talkgroup and
any talkgroup in the RX Group List. When scan is disabled the radio unmutes to the selected talkgroup
but none of the talkgroups in the RX Group List. Enable/Disable Scan only affects the setting of the
selected personality.
1.30
Voice and Data Privacy in Capacity Max
Capacity Max supports a way to keep communication (both voice and data) private. Privacy protects
the information, where “protection” means that it resists reading of data payload or listening of voice by
anybody other than the intended receivers.
1.30.1
Types of Privacy
MOTOTRBO offers Basic Privacy and Enhanced Privacy mechanisms. Capacity Max offers Enhanced
Privacy mechanism. Capacity Max does not support Basic Privacy.
Enhanced Privacy is licensed in the subscriber. It can be utilized in Capacity Max and other
MOTOTRBO architectures. Enhanced Privacy utilizes ARC4 algorithm with 40 bit keys.
85
MN003523A01-AC
1.30.2
Strength of the Protection Mechanism
Enhanced Privacy does not provide resistance against “replay attack” (when an unauthorised person
intercepts the data and retransmits it) or “traffic analysis” (disclosure of information that can be inferred
from observing the traffic patterns).
The protection mechanisms require a key that is shared only among the intended parties. It does not
use any hardware-based cryptographic engine or a hardware-protected memory for storage of keys.
The resistance provided by Enhanced Privacy’s resistance is summarized below:
• Enhanced Privacy uses a cryptographic algorithm to transform plain voice/data into protected voice/
data. The algorithm is known as ARC4. (Alleged RC4), which is the same as RC4. A cryptographic
algorithm makes it very difficult for an unauthorised person to obtain the key from over-the-air
protected messages. The name “RC4” is trademarked by RSA Security. “Unofficial”
implementations are legal, but the RC4 name cannot be used.
• Enhanced Privacy uses 40 bit long keys. A radio can store up to 16 keys and Enhanced Privacy
allows using different keys for different personalities. The large number of possible keys
(approximately 1 trillion) makes it difficult for an unauthorised person to guess the value of a key. A
40 bit long key may not provide the protection needed to transmit valuable data such as credit card
numbers.
• Using the same key, the Enhanced Privacy protects each superframe of voice or each data packet
in a different and unrelated way. This increases the resistance further.
1.30.3
Scope of Protection
Enhanced Privacy protects only the voice and data messages (including IP/UDP headers). The layer 2
voice and data headers, data response packets, and link control data are not protected. This means
that the source and target individual ID and Group IDs are not protected. Control messages such as
Radio Disable, Remote Monitor, Radio Check, Call Alert, Status Message and the embedded and
standalone digital signaling are also not protected. High Efficiency Data messages are not protected as
well.
Enhanced Privacy protects individual voice call, group voice call, site wide voice call, multi-site voice
call, system wide voice call , emergency call, and all packet data calls (individual, group, unconfirmed,
and confirmed).
The protection is provided through all the communication paths between the sending radio and the
destination radio. This implies that the voice and data messages remain protected over-the-air, inside
repeaters, and over the backend network between RF sites.
Voice is protected between the radios and voice application (Voice Console, Logging Recorder,
Telephone Gateway, and others). The MNIS VRC Gateway forwards protected voice to the voice
application. The protection between any voice application servers and their voice application clients are
the responsibility of the application developer.
Data is protected between the radios and MNIS Data Gateway. Any data that extends past the MNIS
Data Gateway is not protected. For example, text messages from a radio to dispatchers or e-mail
addresses on a network are not protected once they leave the MNIS Data Gateway or the destination
radio (a Control Station). A VPN tunnel with IPSec can be utilized between the MNIS Data Gateway
and a data application server. The protection between a data application server and their data
application clients is the responsibility of the application provider.
Enhanced Privacy does protect the voice and data messages between a radio and its option board or
between a radio and its accessory (including a MDT).
86
MN003523A01-AC
1.30.4
Effects on Performance
Enhanced Privacy uses multiple keys and a random number to ensure that the encryption data is
different for each data message and each superframe of a voice message. This requires transporting
crypto parameters (for example, Key Identifier, Initialization Vector) with the voice or data payload. The
replacement of payload bits slightly reduces the voice quality, but this is barely noticeable. A voice
message requires an additional header and replaces some of the least important bits of the voice
payload with the Initialization Vector. The additional header increases the System Access Time by
60ms, which is barely noticeable.
A data message requires an additional header to distinguish between an unprotected data message
and a protected data message. The additional header is also used to transport crypto parameters. This
reduces the data throughput. For example, a typical protected confirmed location response takes 600
milliseconds compared to 540 milliseconds for an unprotected one (approximately 10% loss in
throughput).
1.30.5
Privacy Configuration
All Enhanced Privacy keys utilized in a Capacity Max system are entered using Radio Management
(RM). The radio’s privacy configuration and keys are programmed using RM via USB, Bluetooth, Wi-fi,
or over the air on the radio system. The MNIS Data Gateway’s privacy configuration and keys are also
programmed using RM. RM exports a file which is manually transferred to the MNIS Data Gateway
computer.
For more information how to configure privacy keys into the system and the various configurable
options for transmitting and receiving privacy, see "Voice and Data Privacy Configuration" in the
1.31
Capacity Max Information Assurance
This article describes features and configurations that provide a level of Information Assurance for the
information and information services in a Capacity Max System. In a Capacity Max system the
information being protected includes in transit digital voice and data from a source device to a
destination device as well as the configuration data unique to the system.
Information Assurance (IA) protects information and information systems by ensuring following
attributes:
• Availability: Timely and reliable access to data and services for authorized users.
• Integrity: Protection against unauthorized modification or destruction of information as well as the
physical and electronic systems.
• Authentication: A means of identifying users or assets (for example, passwords, fingerprints, PIN,
ESN, and others) as recognized individuals or assets that have authorized access to network and
system elements.
• Confidentiality: Assurance that information is not disclosed to unauthorized individuals, processes
or devices.
• Non-Repudiation: Proof of a sender’s and recipient’s identities so that neither party can later deny
having been part of the transaction.
87
MN003523A01-AC
1.31.1
Over The Air IA Confidentiality, Integrity and Authentication
The following features support the Information Assurance principles of Confidentiality, Integrity and
Authentication over the RF link in a Capacity Max System.
Registration Authentication
A Capacity Max system has an option to require the infrastructure to authenticate a radio attempting to
register. The authentication procedure includes the validation of the radio's Physical Serial Number or
PSN. It is recommended that authentication is enabled. For more details on over the air authentication
see Radio Access Restriction in Capacity Max System on page 59.
Stun and Revive Authentication

The system may be configured to require authentication during the stun and revive processes. If a
radio initiates one of these commands, the infrastructure authenticates the initiating radio. Regardless
of whether or not the command was initiated from a wireline console or a radio, the target radio
authenticates the infrastructure. For more details on over the air authentication see Radio Access
Restriction in Capacity Max System on page 59.
Kill Authentication
Regardless of whether or not the system requires authentication during registration, it does require
authentication during the Kill process. The target radio of a Kill command authenticates the
infrastructure. For more details on over the air authentication see Radio Access Restriction in Capacity
Max System on page 59.
Voice and Data Privacy

Capacity max supports the ability to encrypted/decrypt voice payload and data payload when
transmitted over the air. ARC4protocol is supported. For more deatils on over the air privacy see Voice
and Data Privacy in Capacity Max on page 85.
1.31.2
IP Network IA Confidentiality, Integrity and Authentication
The following feature of a Capacity Max system support the Information Assurance principles of
Confidentiality, Integrity and Authentication over the back end IP network.
Capacity Max requires usage of a VPN when operating over a public network. VPN configuration
provides a high level of protection, which can include authentication and encryption. All system
messages, control messages, data messages and voice are afforded this high level of protection. For
more details on various VPN options for authentication and encryption see IP Bandwidth Per Site
Requirement for Capacity Max on page 153.
1.31.3
System Configuration and Radio Database Confidentiality and
Authentication
The following feature in a Capacity Max system support the IA principles of Confidentiality and
Authentication for the System Configuration and Radio Database.
Radio Management is used to configure the Capacity Max system and to maintain a list or permitted
services for each radio in the system. Access to Radio Management requires a username and
password
88
MN003523A01-AC
1.31.4
Information Assurance (IA) Availability
The following features in a Capacity Max system support the IA principle of Availability.
Control Channel Rollover

A Capacity Max system supports up to 4 control channel frequencies per site. If an active control
channel detects interference, thus reducing the inbound operating coverage area, the control channel
is moved to one of the other available control channel frequencies. This scenario reduces the site's
available traffic channels by 2. For more details see "Fault Tolerance" in the Capacity Max Installation
and Configuration manual.
Multiple Site Switch Configuration

A Capacity Max system supports multiple site switches in order to preserve wide area communications
at typically half capacity. For more deatils see "IP Network Multiple Site Switch Configuration" and
"Fault Tolerance" in the Capacity Max Installation and Configuration manual.
Site Trunking
Capacity Max supports site (local) trunking upon a network link failure or a router failure at a site. Calls
initiated from a "site trunking" site are local to that site only. In this instance the capacity of the site is
still preserved. For more details see "Fault Tolerance" in the Capacity Max Installation and
Configuration manual.
Single Frequency Pair Site Trunking

Upon a switch failure when multiple switch configuration is not deployed, or multiple switch failures
when multiple switch configuration is deployed, all control channel capable repeaters become active
control channels. Radios congregate to the lowest configured repeater ID at the site. Calls initiated are
local and the capacity is reduced down to one traffic channel. For more details see "Fault Tolerance" in
the Capacity Max Installation and Configuration manual.
Trunking Controller Redundancy

Capacity Max supports Trunking Controller redundancy in either co-located or geographic separated
topologies. For more details, see "Server (CMSS) Redundancy" and "Fault Tolerance" in the Capacity
Max Installation and Configuration manual.
MNIS VRC Gateway Redundancy

Capacity Max supports MNIS VRC Gateway redundancy. For more details, see "Server (CMSS)
Redundancy" and "Fault Tolerance" in the Capacity Max Installation and Configuration manual.
MNIS Data Gateway Redundancy

Capacity Max supports MNIS Data Gateway redundancy. For more details see "Fault Tolerance" in the
Repeater Hardware Redundancy

Capacity Max supports Repeaters (control channel, traffic channel and data revert) Hardware
redundancy. For more information, see "Repeater Hardware Redundancy" in the Capacity Max
89
MN003523A01-AC
ADVPN VAM Server Redundancy

Capacity Max deployments with HPE Routers supports a single redundant ADVPN VAM Server. The
ADVPN VAM server is used to dynamically set up VPN tunnels between sites. The primary and
redundant ADVPN VAM servers are located at geographically different sites. Upon failure of the
primary ADVPN server the redundant VPN server is utilized to continue supporting wide are trunking.
For more deatils see "Troubleshooting the ADVPN in Capacity Max Routers" in the Capacity Max
System Operations, Troubleshooting, and Maintenance Guide.
Fault Management
The Capacity Max System Advisor provides a system component inventory view, logs call traffic and
reports alarms and events. The system supports up to 5 System Advisor servers where up to 2 receive
call traffic and all recive alarms and events. For more details, see "Capacity Max Infrastructure
Inventory" and "Capacity Max Alarms and Events" in the Capacity Max System Operations,
Troubleshooting, and Maintenance Guide.
System Configuration and Radio Database Restoration

Capacity Max Radio Management supports backup and restore functionality of the system's
configuration as well as its radio privilege database. In the case of a CMSS hardware failure, a new
CMSS can quickly be configured as a replacement.
1.31.5
IA Non-Repudiation
Non-repudiation consists of mechanisms to provide proof of the integrity of the data and to assert that
the data's source is genuine with high assurance. Non-repudiation in a Capacity Max system relies on
MOTOTRBO third party applications that support data at rest. Data at rest examples includes, but is
not limited to: voice recording, text messages and location updates.
1.32
Capacity Max Job Tickets
Job Tickets (also known as Work Tickets) is a feature that helps customers in managing job tickets
associated with radio users. This feature is useful in service organizations (for example hotel, taxi,
security, and others).
The feature consists of the following applications that communicate using a special protocol:
• An application running on a PC through which a customer can create and assign jobs to radio
users.
• A set of applications running on radios through which radio users can change the states of the
assigned jobs to a different pre-configured state; For example, from “New” state to “In Progress”
state.
• A protocol for communication between the PC-based application and the radio based application.
There are a number of PC-based applications developed by third party application developers.
NOTICE: The PC-based application for Enhanced Job Ticket is not compatible with the legacy
Text Message-based job ticket application.
90
MN003523A01-AC
1.32.1
Job Ticket Registration
The Subscriber Unit ID (SUID) and User ID registrations are supported via the CSBK messaging as a
radio-wide feature in Capacity Max mode.
The PC-based Job Tickets application supports the Capacity Max Presence Interface. The PC Job
Tickets presence application registers with the Capacity Max Controller's Presence Interface, receives
the radio's SUID and User ID, and associates them for device and user-level Job Tickets management.
Figure 4: Registration Communication System Topology
Subscriber Unit Trunk Controller PC
Presence
Registration Control Channel Presence Application
Job Tickets
Application Manager Interface App
Job Tickets (HotSos)
Protocol App
(MBXML/XML)
LMR Wireless
Network
MNIS
1.32.2
Job Ticket Configuration
To send job tickets from a radio to the PC-based Job Tickets application, you must configure the radio
with the Server ID and Server UDP Port of the PC-based application using the Radio Management
(RM) application.
The Server ID is the radio ID of the MNIS Data Gateway used by the PC-based application.
The radio supports a fixed internal receive UDP port (4013) for receiving Job Tickets. The PC-based
application can send job tickets to a single radio or a group of radios through the MNIS Data Gateway.
The radio sends back the response by using its IP address and a fixed UDP port (4013) as the source,
and the destination IP address and port from the received message.
The radio also supports a configurable “Forward to PC” option for forwarding the received Job Tickets
to the PC connected to it. All job tickets targeted to the radio-based application are forwarded to the
locally connected PC.
The job ticket's IP datagram is sent over a trunked channel between the radio and the MNIS Data
Gateway. The maximum Job Ticket data payload size is 1000 bytes. The MNIS Data Gateway handles
the routing of the data to/from the PC-based application. For more information, see Application
Deployment Options with MNIS Data Gateways on page 141 and "MNIS Data Gateway Configuration"
in the Capacity Max Installation and Configuration manual.
1.32.3
Job Tickets Inbox Folders
A radio stores all received Job Tickets into two inboxes: “My Tasks” and “Shared Tasks”. If the
received job ticket is public, then it is stored in the “Shared Tasks” inbox, which could be accessed by
any user. If the received job ticket is addressed to a specific user, then it is stored in “My Tasks”, which
can be accessed only by the matching user. If the PC-based application sends a job ticket to a specific
user and the user is not logged into the radio, the radio stores the ticket without providing any user
feedback. When the matching user registers onto the radio, his/her private job tickets are accessible.
The “My Tasks” and “Shared Tasks” combined store up to 500 received tickets. When they are full, the
oldest completed task is deleted. The radio sends a onetime broadcast message for a deleted
message to the PC-based application.
91
MN003523A01-AC
When the status of a job ticket is modified, the radio sends a response message to the PC-based
application and moves the ticket to a Status folder. The Action/Response and Status Folders are
configurable in Radio Management. Both “My Tasks” and “Shared Tasks” share the same Action/
Response and Status Folder configuration.
1.32.4
Radio Created Job Tickets
The radio supports creating a new Job Ticket and sends it to the preconfigured PC based application
(Server ID and Server UDP.) The new ticket must conform to the Job Ticket Templates configured in
the Radio Configuration within Radio Management.
After sending the ticket to the PC based application, the ticket is stored in the Job Ticket outbound
“Sent Tasks” folder with a success or failure icon for message sent status. The user can resend any
failed messages via the Sent Tasks menu. The Job Tickets “Sent Tasks” folder can store up to 30
created tickets. When the “Sent Tasks” folder is full, the oldest ticket is deleted for storing a newly
created ticket.
1.32.5
Delete All Job Tickets
The radio supports a Radio Management configurable option for deleting all Job Tickets (public or
private) at power up.
1.32.6
Presence of a Radio/User in Capacity Max
A Capacity Max system provides the presence/absence of a radio or its user through its Presence
Interface in its Trunking Controller. The PC-based Job Tickets application uses the Capacity Max
Presence Interface by subscribing for the radios/Users whose job tickets it is managing. User Name
Verification Application is also supported. For more information, see Capacity Max Presence of a
Radio User on page 93.
1.32.7
Job Tickets Data Communication
An Enhanced Job Tickets Protocol (EJTP) specification is used for communication between the Job
Ticket applications in a radio and in the PC. The Job Tickets Protocol uses XML documents, which is
compressed using Motorola Binary Extensible Markup Language (MBXML) for OTA transmission.
1.32.8
MNIS Networks
There are three types of MNIS Networks in Capacity Max system, as follows:
CAI Network
This field must be the same as Comment Air Interface (CAI) Network assignment of the radios. A
radio has multiple CAI IP addresses such as Internal Network Address, External Network Address,
and Bluetooth Network Address. The addresses are Class A addresses using the network IDs such
as CAI Network, CAI Network+1, and CAI Network+2. As a default CAI Network setting, the CAI IP
addresses have Class A network IDs of 12, 13, and 14. You can use the default assignment unless
the radio IP addresses resulting from the default setting conflict with the IP addresses of other
devices on your network. For more information, see Application Deployment Options with MNIS
Data Gateways on page 141.
92
MN003523A01-AC
CAI Group Network

This field must be the same as CAI Network assignment of the talkgroup, and also must be the
same as CAI Group Network assignment of the radios. Talkgroups have Multicast IP addresses
with network ID of CAI Group Network. The consideration is similar, as CAI Network applies for CAI
Group Network.
Job Tickets UDP Port
This field represents the Job Tickets Data Application UDP port. Typically you can use the default
assignment since most of the MOTOTRBO Job Tickets applications use this port as default. If there
is port conflict, this port could be changed.
1.33
Capacity Max Presence of a Radio User
A Capacity Max system allows applications to obtain and track the presence of radio users via the
Presence Notifier interface provided by the Trunking Controller. This is a proprietary feature, which
means that this feature is available only for MSI’s radios in “Advantage” mode on a Capacity Max
system. This feature works with the keyboard and display capable radios only.
The Trunking Controller receives a user’s presence from the user’s radio when the user registers
his/her User ID via the radio.
1.33.1
User ID
A User ID consists of the following fields:
• User Name: The User Name has 1 to 14 characters, where a character is in the set {0..9 A..Z *
# , . ?}.
• Domain ID: A User Name is unique within its domain, i.e. the scope of a User Name is its domain.
Associated with a domain is an application that verifies the names. Verification Application serves
one or more domains. A Verification Application for a domain is provided by the customer who owns
the domain.
The concept of Domain is useful when a Capacity Max system is being shared by multiple
customers. Each customer can have its own domain. A customer needs to ensure that a user’s
name is unique within its domain and (not necessarily within the system). Same user name can be
used across domains.
Within a system, a radio is associated with one domain only. This implies that a User Name in a
domain can register only with a radio that is associated with the domain.
The range of Domain ID is 0 to 16. The domain ‘0’ has no Verification Application and therefore no
verification of the User Name is done by the system.
A radio’s User Name Domain ID is specified in the Subscriber Access Control within Radio
Management. The User Name Domain ID defines the User Name Verification Application the
system utilizes to validate the user name entered by the radio user. A User Name Verification
Application is added to the system set and the Domain ID is specified. A Domain ID of 0 means that
the User Name is not verified. For more information, see the "System Parameter Configuration" in
the Capacity Max Installation and Configuration manual.
1.33.2
User Interface
The radio allow its user to register (to input his/her User Name using keypad or menu.) only while a
radio is registered and has no registered user. The radio remembers up to five of the most recent User
Names and allows the user to select one of them.
93
MN003523A01-AC
A radio can have only one registered user at a time. If the radio has a registered user and a different
user tries to register, then the radio prompts to deregister the old user first.
The radio user can acquire the current status of the user registration and the registered User ID
through the radio menu.
On de-registration of a radio (in case of power-off, or automatic deregistration), the radio and the
system deregister the user. The registration of a user at a radio removes its association with any other
radio.
Within Radio Management, the “Sign In / Sign Out” field in the general settings of the radio
configuration enables the feature in the radio. Once enabled, the “Secure Sign In ID” field is available.
This check box allows the user to specify whether or not the Sign In ID is shown on the Home Screen
and if it is partially hidden when the user is entering the Sign In ID. For more details, see "Trunking
Subscriber Configuration" in the Capacity Max Installation and Configuration manual.
1.33.3
Verification of Users Name
If the Domain ID of the radio is zero then the system does not verify the User Name.
If the Domain ID of the radio is non-zero then the system sends the User Name and the Domain ID to
the verification application of the domain. If the system either receives a verification failure response or
receives no response (after three attempts) from the verification application, then the system does not
register the user.
Verification Applications are specified in the System Set within Radio Management. A Domain ID, IP
Address, and UDP Port must be specified. For more details, see the "System Parameter Configuration"
in the Capacity Max Installation and Configuration manual.
1.33.4
Verification Application Redundancy
In Capacity Max system, one verification application IP address, and port can be configured for one
domain ID. If a customer requires verification application redundancy, it can be accomplished by
configuring the router at the CMSS site, to forward the UDP packet to both primary and redundant
verification applications.
The solution requires the following:
1 R2.7.7 (MOL) / R2.8 or later version of the Trunking Controller, that supports UDP packets to local
broadcast address.
2 Configuration of verification application IP address to 255.255.255.255, and UDP port to 62000 or
above.
3 Configuration on router, or layer 3 switch.
The proposed solution makes use of UDP helper feature (HP terminology) on the router to forward
local broadcast UDP packet on a specified UDP port to both primary and redundant verification
applications. It is recommended to use UDP port equal to or greater than 62000, to prevent any
interaction with other applications on the Capacity Max System Server.
Example: In this following example:

Domain ID = 1
Primary verification application IP address = 10.50.31.24
Primary verification application UDP port = 62000
Redundant verification application IP address = 10.50.32.24
Redundant verification application UDP port = 62000
94
MN003523A01-AC
Required Configurations
The following are the required configurations:
1 Configuration of user name verification application IP address in Capacity Max system
Domain ID = 1
Verification Application IP address = 255.255.255.255 (local broadcast)
Verification Application UDP Port = 62000
2 Configuration on HP router that is connected to primary / alternate Trunking Controller
# Enable UDP helper
<RouterA> system-view
[RouterA] UDP-helper enable
# Enable UDP helper to forward broadcast packets with the UDP destination port 62000
[RouterA] UDP-helper port 62000
# Specify the destination server 10.2.1.1 on the Trunking Controller interface (In this example the
Trunking Controller is connected to the interface GigabitEthernet 2/0/1 )
[RouterA] interface gigabitethernet 2/0/1
[RouterA-GigabitEthernet2/0/1] UDP-helper server 10.50.31.24
[RouterA-GigabitEthernet2/0/1] UDP-helper server 10.50.32.24
3 Configuration on Cisco router that is connected to primary / alternate Trunking Controller
L3(config)#IP forward-protocol UDP 62000
On the router interface connected to the trunking controller, configure the following:
L3(config-if) IP helper address 10.50.31.24
L3(config-if) IP helper address 10.50.32.24
1.34
Capacity Max Architecture and Configurations
This section identifies the entities of a Capacity Max system, and describes some of the possible
topologies.
Overview
The following figure shows an example of the Capacity Max system configuration. It consists of two RF
sites, one management site, and two application sites. A RF site has one or more trunked repeaters,
zero or more data revert repeaters, and optionally clients of management applications such as radio
management, and system advisor. A RF site may also have some other site equipment such as power
monitor. A management site has Capacity Max servers, Motorola Solutions supplied system
management applications (for example, radio management and battery management), and third party
supplied system management applications (for example, GW3–TRBO from Genesis). An application
site has data applications (for example, location server and Text message server), which interface with
a MNIS Data Gateway. It may also have voice applications (for example, console, voice recorder, and
telephone gateway), which interface with a MNIS VRC Gateway. All the above mentioned entities
communicate over the IPv4 based network. The following sub-sections briefly describe the entities of a
Capacity Max system.
95
MN003523A01-AC
Figure 5: Capacity Max System Configuration
CMSS2
RF Site 1 CORE/MANAGEMENT SITE
TC System VRC GW
Advisor 3rd Party
CMSS1
Gen
Control Channel TC System VRC GW
+ Trunk Advisor Genesis
Trunk Trunk Data Data Switch Site Equipment

Revert Revert
Switch Data GW RM
Router Battery Management System Advisor
Radio Management, Router
System Advidor Modem Battery
Management
Modem
MSI RM
PUBLIC
INTERNET 3rd Party 3rd Party
Switch
RF SITE N Switch
Router
Router
LOC TMS
Switch
Data GW Switch
Control Channel CON CON

+ Trunk
Data Data Data GW

Trunk Trunk Switch Site Equipment 3rd Party 3rd Party
Revert Revert
Router LOC Console LOC Console
Radio Management, LOC

LOC
System Advidor Modem
TMS TMS
TMS CON CON

TMS
Application Site 1 Application Site N
Network Equipment Radio Client

Repeater Gateway Console
Server External
Gateway (GW)
1.34.1
Communication Network
The communication network of a Capacity Max system consists of a set of IPv4 based local networks
(one per site), and an IPv4 based back-end network that connects all the local networks.
The local network is used for intra site communication between entities at a site. All Capacity Max
repeaters at a RF site are connected over a LAN, and they must be in the same IP subnet. Two or
more RF sites do not share a subnet and a RF site, and a RF site do not share a subnet with a voice or
data gateway.
The back-end network is used for communication between sites and with the Application Servers.
Capacity Max supports a wide variety of back-end networks, from a dedicated network to an Internet
provided by an Internet service provider (ISP). The back-end network of Capacity Max should not be
based on “dial-up” connection due to small bandwidth, or Satellite Internet access due to large delay.
The types of connection between the LANs and the back-end network results in multiple network
topologies. The following network topologies are supported by a Capacity Max system:
• Native Private Network
In a Native Private Network, all the entities over the LANs and back-end network are in the same
private network. The IP addresses over all the LANs are in the IP address space of the back-end
network. Thus, the customer determines the IP addresses and subnets that the Capacity Max system
can use.
• Virtual Private Network
In a Virtual Private Network, the private networks of sites are tunneled across the public network of the
back-end to form a single private network. The IP addresses over all the LANs are in the same IP
address space, but the IP addresses over the back-end network are in a different address space. It
enables entities to send and receive data across shared or public networks, as if it is directly connected
96
MN003523A01-AC
over a private network. A Virtual Private Network is created by establishing a virtual site-to-site
connection through the use of either dedicated connections or virtual tunneling protocols. The Capacity
Max primary use case employs a router with site to site VPN. When a VPN is being used, all external
applications like the servers and clients must reside in the same VPN, as the core radio and gateway
equipment. The clients can be outside of VPN, if static NAT is configured in the routers or a remote
access VPN solution is installed.
In certain circumstances, the private networks of sites are connected together by mapping every
address in use in a private network, to a corresponding address in the public network of the bac-kend.
This is often accomplished by Network Address Translation implemented in a routing device. The IP
addresses of all the LANs are in different IP address spaces, but they are mapped to a common the IP
address space of the back-end network. A Capacity Max system does not support this configuration.
Figure 1 shows, the entities are segregated amongst three basic network types (Radio Infrastructure,
Gateway and Application), which reside on various Virtual LANs or VLANs. This type of segmentation
is required at most physical locations. It is dependent upon physical location of equipment and is
accomplished with 802.1q VLAN tagging. The following rules apply, when determining required VLAN
segregation at a physical location:
• Co-located RF sites must reside on separate Radio Network subnets.
• Co-located Capacity Max Servers (CMSS) must reside on separate Gateway Network subnets.
• Co-located MNIS VRC Gateways must reside on separate Gateway Network subnets.
• Co-located MNIS Data Gateways must reside on separate Gateway Network subnets.
• Any of these four (RF sites, CMSS, MNIS VRC gateways, and MNIS Data Gateways) must reside
on separate subnets from each other.
1.34.2
Sites
A site is a physical location, where a set of repeaters, servers or PCs are connected over a LAN. There
is an exception to this, where a physical location may have two or more virtual LANs. In that case,
each virtual LAN is a site.
A RF site supports one or more frequency pairs, where each frequency pair supports two Over-The-Air
(OTA) communication paths, that is logical channels.
All the frequencies used at a site must be within the band(s) supported by the radios that intend to
operate at the site. This implies that all the sites where a radio can roam should have the frequencies
from the same band(s). Since, MOTOTRBO radios support both 800 and 900 MHz bands, a site can
have frequency pairs from both the bands. A Capacity Max system can have sites from different bands.
An OTA communication path is used as a control channel, a trunked channel (used for voice or data),
or a data revert channel. A RF site can have one to four candidate control channels. In Capacity Max,
a control channel is always the first slot of a frequency pair. The frequency pairs of the candidates
control channels are dedicated (that is, not shared with any other system).
For a talkgroup call, a site can have only one inbound communication path (Over-The-Air and Over-
The-Wire) active at a time. This implies that two MNIS VRC Gateways cannot be on the same LAN,
and a MNIS VRC Gateway cannot be on the LAN having repeaters.
1.34.3
Gateways
Capacity Max offers a MNIS Data Gateway, which acts as a gateway for data messages exchanged
between radios and data applications (for example, the location server, text message server, radio
97
MN003523A01-AC
management, and battery management). A MNIS Data Gateway is recommended at a site where a
data application is present.
In lieu of a MNIS Data Gateway, a control station can be used to receive data messages over a revert
channel. This will require one conventional control station per data revert channel for each site;
because a Capacity Max system does not support wide-area data revert channels. If control stations
are required to receive over payload channels (trunked), then the control station should be a Capacity
Max radio.
NOTICE: Capacity Max system does not encourage interfacing data applications through
control stations.
Capacity Max system also offers a MNIS VRC Gateway, which provides interface for consoles, voice
recorders, and telephone to participate in voice calls.
1.34.4
Servers
A Capacity Max System Server (CMSS) is a computing platform where one or more system
applications such as the trunking controller, system advisor, and VRC gateway run.
NOTICE: A data gateway does not run on a CMSS, but on its own server. A dealer is not
allowed to put applications on a CMSS. The applications should run on their own servers.
The main function of a trunking controller is to allocate resources (for example, channels and
gateways) to calls in an efficient way. The trunking controller also provides the presence information of
radios to data applications, and performs access control and authentication of radios. The system
advisor, which follows a client-server model, is responsible for the following:
• Displaying and logging alarms/events/status of repeaters and gateways
• Displaying and logging call information from repeaters and gateways
• Performing control operations on repeaters
1.34.5
Deployment of Topologies
This section briefly explains some deployment topologies, a representative subset as to provide
guidance.
NOTICE: All of the lighter colored boxes in the diagrams represent a physical machine.
For deployments of data applications, the two most common deployments are with the MNIS Data
Gateway on the same server as data application, and with the MNIS Data Gateway on a different
server as the data servers and clients. The following are recommended with respect to the network
type, if there is only one NIC per the data gateway machine:
• Servers and clients (Motorola Solutions or third party) on a machine with the data gateway reside
on the Gateway Network.
• Motorola Solutions servers and clients not on a machine with the data gateway reside on the
Gateway Network.
• Third party servers and clients not on a machine with the data gateway reside on the Application
Network.
The following figure shows the Capacity Max system topology, where two RF sites are co-located and
sharing the same router. In this scenario, the two RF sites should be on two different VLANs.
98
MN003523A01-AC
Figure 6: Two RF sites are co-located in Capacity Max System Topology

CMSS2
RF SITE 1 MANAGEMENT SITE
TC System VRC GW
Advisor 3rd Party
CMSS1
Gen
TC System VRC GW
Advisor Genesis
Site Equipment
Control Channel
+ Trunk
Switch Data GW RM
Battery Management System Advisor

Router
Trunk Trunk Data Data Battery
Revert Revert
Management
Modem
MSI RM
RF SITE N PUBLIC
Modem
Modem
Control Channel
+ Trunk Router
Router
LOC TMS
Switch
Data GW Switch
Data Data CON CON

Trunk Trunk Revert Revert
Data GW
3rd Party 3rd Party
Switch
LOC Console LOC Console
LOC
Router LOC
TMS TMS
Radio Management
System Advisor Modem
TMS CON CON
TMS

Server External
Gateway (GW)
The following figure shows the Capacity Max system topology, where the core site (that is the Capacity
Max System Server) is co-located with a RF site. In this scenario, the core site and the RF site should
be on two different VLANs.
Figure 7: Core Site is co-located with a RF Site in Capacity Max System Topology
RF Site 1 Management Site
3rd Party
CMSS1
System Gen
TC Advisor VRC GW
Control Channel Genesis
+ Trunk

Revert Revert
Data GW RM
Switch
Router Battery Management System Advisor
Router
Radio Management, Battery
System Advisor Modem Management
Modem MSI RM
PUBLIC
Modem
RF Site N Modem
Router
CMSS2 Router
LOC TMS
System Switch
TC Advisor VRC GW Data GW Switch
Control Channel CON CON

+ Trunk
Data Data Data GW

Trunk Trunk Switch Site Equipment 3rd Party 3rd Party
Revert Revert
Router LOC Console LOC Console

LOC
Radio Management, LOC
TMS TMS
TMS CON CON

TMS

Server External
Gateway (GW)
99
MN003523A01-AC
The following figure shows the Capacity Max system topology, where the core site (that is the Capacity
Max System Server) and the management sites, are co-located with a RF site.
Figure 8: Core and Management Sites are co-located with a RF Site in Capacity Max System
Topology
Application Site N Modem RF / Management Site MSI
3rd Party
CMSS2
Router System Advisor
RM Client
TMS TC System VRC GW
Advisor
Switch Battery
Management RM
CMSS1
CON
System Data GW
TC Advisor VRC GW Battery
3rd Party
Data GW Management
Control Channel
LOC Console
3rd Party
LOC Trunk Trunk Data Data Switch
Revert Revert
TMS Gen
Router
CON
TMS
Genesis
Modem
Application Site 1
Modem
3rd Party
Router PUBLIC
INTERNET
Switch LOC
Data GW RF Site N
CON
Control Channel
+ Trunk
3rd Party
Console Trunk Trunk Data Data Switch Site Equipment

LOC Revert Revert
LOC
Router
TMS
CPS-RM,
TMS CON System Advisor Modem

Server External
Gateway (GW)
The following figure shows the single site Capacity Max system topology, where all the entities are at
the same location.
Figure 9: Single Site Capacity Max System Topology
RF / Management / Application Site
CMSS2 MSI 3rd Party
System System Advisor

TC Advisor VRC GW LOC Console
RM Client
LOC
Battery
Management TMS
RM
CMSS1
TMS CON
System Data GW
TC Advisor VRC GW Battery
Management
Control Channel
+ Trunk
Data Data
Trunk Trunk Revert Revert
Switch 3rd Party 3rd Party 3rd Party
Gen Gen Gen

Router
Genesis Genesis Genesis

Server External
Gateway (GW)
100
MN003523A01-AC
The following figure shows the Capacity Max system topology, where the RF sites, the core site (that is
the Capacity Max System Server), and the application sites are in the customer network.
NOTICE: The network equipments at the Management Site and the connectivity are not
specified in the diagram. Customers can reach to their IT department to find an acceptable
solution. It might be a VPN between the management site and core site, a remote access VPN
built up on demand, or others.
Figure 10: RF, Core and Application Sites at Customer Network in Capacity Max System
Topology
RF Site 1 Management Site
Genesis
PUBLIC * Consult with customer’s IT department

for acceptable equipment Genesis
INTERNET
Control Channel
+ Trunk
Data GW RM
Trunk Trunk Data

Revert
Data
Revert Switch Site Equipment * Battery Management System Advisor
Battery
Router Management
Modem MSI RM
CPS-RM,
CMSS2
System Data GW
TC Advisor VRC GW
RF Site N CUSTOMER LOC

PRIVATE Console
NETWORK CMSS1
System TMS LOC

Control Channel TC Advisor VRC GW
+ Trunk
TMS CON
Revert Revert
Router 3rd Party 3rd Party

Switch
CPS-RM,
Router
TMS TMS
Modem
CON CON
Application Site

Server External
Gateway (GW)
The following figure shows the Capacity Max system topology, where the RF sites, the core site (that is
the Capacity Max System Server), the management site, and the application sites are in the customer
network.
101
MN003523A01-AC
Figure 11: RF, Core, Management and Applications Sites at Customer Network in Capacity Max
System Topology
Monitor (Dealer) Site CMSS2
System Data GW
TC Advisor VRC GW
System Advisor
LOC RM
CMSS1 Console
LOC Battery
System TMS Battery
RM Battery Management TC Advisor VRC GW Management
Management
TMS CON
RM
System Advisor Switch
* Consult customer’s IT department

* for acceptable equipment Router
3rd Party 3rd Party 3rd Party
Genesis
CUSTOMER Modem
PUBLIC PRIVATE TMS TMS
Genesis
Modem INTERNET NETWORK
CON CON
Management / Application Site
Control Channel Control Channel

+ Trunk + Trunk
Data Data Trunk Trunk Data Data Switch Site Equipment

Trunk Trunk Revert Revert Switch Site Equipment Revert Revert
Router Router
CPS-RM, CPS-RM, Modem

System Advisor Modem System Advisor
RF Site N RF Site 1

Server External
Gateway (GW)
NOTICE: The network equipments at the Monitor Site and the connectivity are not specified in
the diagram. Customers can reach to their IT department to find an acceptable solution. It might
be a VPN between the management site and core site, a remote access VPN built up on
demand, or others
1.35
Capacity Max Over-the-Air Data Transport
A data message in Capacity Max can be sent on a trunked channel, a control channel, or a revert
channel, over the air. Each channel type has certain limitations for over-the-air data transport. Capacity
Max also provides a proprietary method to send confirmed group data.
1.35.1
Data over Trunked Channels
In Capacity Max system, you can send data messages over trunked channels. Review the benefits and
limitations of this data transport method to see if it meets the needs of your system.
The process of sending data messages over a trunked channel has the following stages:
1 A radio sends a “request”over the control channel by randomly accessing the control channel.
2 If the destination is an individual radio, the system checks the availability of the destination. The
system checks the availability of the destination by sending one outbound burst and one inbound
burst.
3 The radio receives a “grant” to use a specified trunked channel over the control channel. The
system sends two outbound bursts.
4 The radio moves to the trunked channel.
Sending data over trunked channels has the following advantages:
102
MN003523A01-AC
• This mode uses the control channel for sending data from a radio to another radio, from a radio to a
data application, from a radio to a talkgroup, and from a data application to a radio. An option board
in a radio, or a peripheral connected to a radio can send or receive data messages using this mode.
• It supports encryption of data over the air.
• It supports confirmed delivery of data over the air.
Sending data over trunked channels has the following disadvantages:
• This mode uses the control channel for requesting channels and receiving the grant, which limits
the number of data messages that can be sent at a site. A site only has one active control channel,
which is used by all services (including voice calls). For example, a site can have less than 110
location updates from radios or less than 80 text messages between radios per minute before one
third of a control channel is used by the data messages.
• There is an overhead in use of a trunked channel due to the fact that the trunked channel is idle
while the radios are moving to the trunked channel and the UDP/IP headers increase the size of the
data message. This overhead is significant (approximately 50%) for small messages such as
“location data”.
1.35.2
Data over Control Channel
In Capacity Max, there are two ways of sending data over control channel: Short Data and Status
Message. They are used for text messaging only.
Short Data
In short data, a text message has a limit of 23 characters. Short data allows sending a text message
from a radio to another radio, or from a radio to a talkgroup only. It cannot be used when an application
is either a source or destination of the text message. The short data option/parameter provides a
confirmed delivery of text message, but does not support encryption of data over-the-air. There is
significant overhead in using this. A 23 characters long text message sent from a radio to another radio
takes seven inbound bursts and seven outbound bursts of the control channels. This limits the number
of text messages to less than 33 messages per minute at a site, before one third of a control channel is
used by the text messages. When text messages are destined to a talkgroup, the throughput
decreases further, which depends upon the number of sites associated with the talkgroup.
Status Message
In Status Message, the text message has to be one of the 100 preconfigured text messages. A Status
Message uses the mapping of a pre-configured text string to a number. The mapping is same at both
source and destination. The source and destination can be radios, talkgroups, or third party console
applications. Status Message is more efficient when compared to Packet Data over trunked channel or
Short Data, because there is no payload of channel allocation, and the message is compact. The
Status Message ID is sent as a single burst on the control channel. A site can have up to 110 text
messages between radios per minute, before one third of a control channel is used by the text
messages.
1.35.3
Data over Revert Channel
Transmitting data over revert channel does not use the control channel. A source radio moves to one
of the pre-configured dedicated data channels (Data Revert channels), accesses it, and transmits data
over the channel. These channels (up to 12) increase data call capacity without impacting call capacity
on the trunked channels. Since the destination radio(s) are not on the revert channel, this can be used
only for sending data from a radio to an application.
103
MN003523A01-AC
When there is no synchronization between radios moving to a revert channel and transmitting, the
collision among the radios increases, as the data throughput on the revert channel increases. To
reduce the collisions, a Data Revert channel can be configured as an “Enhanced Data Revert”
channel.
NOTICE: This feature is not supported by Capacity Max.
1.35.4
Data over Enhanced Revert Channel
In an enhanced revert channel, a channel is divided into windows.Windows are the minimum number
of contiguous bursts of the channel required for transmitting data messages over the channel.
A radio requests a window from the repeater and receives reservation over the enhanced revert
channel before transmitting. The reservation contains the identity of the window reserved for the radio.
If a radio requires a periodic transmission of data messages (for example, one location data every
minute), it specifies the cadence in its request and the repeater reserves one window per cadence
period forever. This makes the enhanced revert efficient for transmitting location updates from radios.
The enhanced revert channel supports two types of data payload format - the IP packet data, and high
efficiency data. IP data can be sent on the enhanced revert channel through unconfirmed (clear or
encrypted) radio to the application data. The high efficiency data compresses the location data into
single burst and does not support encryption. An enhanced revert channel with 90% utilization can
support up to 180 location updates per minute, such as IP data, and 900 location updates per minute,
such as high efficiency data. A site can handle up to 14,400 location updates per minute, with up to 12
revert channels.
1.35.5
Confirmed Group Data
When the same data is required to be sent to ‘n’ radios of a talkgroup, then, sending one data
message to this talkgroup is the most efficient way of sending this message. The data over trunked
channel and over control channel support sending unconfirmed data message to a talkgroup. The
Digital Mobile Radio (DMR) Protocol does not support confirmation of a data packet sent to a group.
The disadvantage of unconfirmed data packet is that the reliability of transferring the data decreases
rapidly as the size of data messages increases. For example, if the reliability of one unconfirmed data
burst (12 bytes) is 98%, then the reliability of 32 bursts (384 bytes), is only 52% = (0.98)32.
NOTICE: A confirmed data is more reliable as it uses Selective Automatic Repeat Request
(SARQ), where the sender tries multiple times to transfer the part of the message, which was
received by the target incorrectly.
MOTOTRBO provides a proprietary method to transfer data messages to a group in a confirmed way.
It has the following constraints:
• The data messages can be transferred only from a data application (that is, only through an MNIS
Data Gateway). A radio cannot be a source. The data messages are not sent through a control
station.
• The maximum number of blocks in the message is limited to 40. This limits the size of the message
to 636 bytes, including IP and UDP headers.
• The maximum number of target radios for a message is limited to 200. The target radios must be
MOTOTRBO radios.
• The target radios of a message must be members of a talkgroup.
• A radio, which is participating in a Confirmed Group Data, suspends the Priority Scan during the
Confirmed Group Data.
104
MN003523A01-AC
• It is supported only in the repeater mode (not in direct mode).

• It is supported only in the single site conventional, IP Site Connect, Capacity Plus, or Capacity Max
Systems Advantage Mode (not in open mode).
An application requests to transfer a data message to a set of radios by providing the data payload, a
list of recipient radios, and a talkgroup to an MNIS data gateway.
NOTICE: The destination talkgroup should be an Rx member in all the recipient radios.
The MOTOTRBO system forms and transmits a confirmed packet data unit (PDU) in the same way as
an individual data packet. After transmitting the PDU, the system polls all the recipient radios one by
one for their acknowledgments on the trunked channel. If the response from one or more radios is
negative for the whole PDU or for few blocks, then the system follows the SARQ procedure, which at a
high level is similar to the SARQ procedure for individual data packet.
After the SARQ procedure completion, the MNIS Data Gateway returns to the source (data
application), the success or failure of the transfer for each recipient radio.
In good signal condition (when all radios receive the PDU correctly on the first attempt), the method
takes (p+r+9) * 0.06 seconds of over the air time; where ‘p’ is the number of blocks in the PDU and ‘r’
is the number of recipient radios.
1.36
Capacity Max Bridge
The Capacity Max Bridge (CMB) is a software application that resides on the CMSS, and it bridges
supported call types between a Capacity Max System, and a bridged radio system. The CMB operates
as a Client application of the MNIS VRC Voice Gateway, which resides on the same CMSS. The CMB
shares the same IP address as the co-located VRC Gateway.
MOTOTRBO Connect Plus is supported as a bridged system type. The XRT 9100 Gateway serves as
the CMB's voice gateway to the Connect Plus system.
The CMB is designed to assist during a migration process of finite duration by bridging supported call
types between the two systems, while the existing sites are converted to Capacity Max operation, and
the new Capacity Max sites are added to expand network coverage. Since its primary purpose is to
facilitate complete migration process to Capacity Max thereby allowing radio users to fully use this
Capacity Max feature, the CMB should not be considered as a long term solution in bridging disparate
radio systems.
1.36.1
Capabilities and Features of the Capacity Max Bridge
This section describes the capabilities and features of the Capacity Max Bridge (CMB) application.
The CMB has the following capabilities and features:
• Bridges up to 100 simultaneous calls between Capacity Max and the bridged system. For voice
calls, both clear and encrypted calls are supported. Calls are bridged on a best-effort basis, subject
to the resource constraints of the two bridged systems.
• Push-to-Talk (PTT) ID is sent across the connected systems. The displayed alias is determined by
the programming of the receiving radio.
• Utilizes a Presence interface with both systems to dynamically register and deregister Group IDs
and Radio IDs as needed. When a talkgroup no longer needs to be bridged because it is no longer
registered on both systems, it is deregistered from the gateway devices and group audio is no
longer transported between the systems.
• Assists with Capacity Max Subscriber Access Control (SAC) migration by creating, on user request,
a file that contains a list of Subscriber Unit IDs (SUIDs) and another file that contains Talk Group
105
MN003523A01-AC
IDs from the Connect Plus user database. The files also contain the user and group privileges that
are associated with the listed IDs and that are common to both systems. The files can then be
uploaded to the Radio Management (RM), which creates records for those IDs in the Capacity Max
SAC for Private IDs and in the Talkgroup Site Association list for Group IDs. The newly created Cap
Max entries have IDs and privileges that match the Connect Plus database at the time of file
creation.
• Provides Private ID and Group ID translation tables, configurable through RM, which can be used to
transform IDs as they pass through the CMB, so that a SUID or Group ID used on one system
appears as a different SUID or Group ID on the other system. Most migration strategies do not
require this advanced feature. It is intended for special use cases involving radios and groups that
do not roam between the two systems. It is not intended for cases where the same radios and
groups are used on both systems. which is the typical migration implementation.
• Provides the ability to configure which Talkgroup IDs should not be bridged between systems (if
any).
• The Capacity Max Bridge provides a means to monitor CMB connections and status through the
System Advisor (SA) and/or through the CMB web service page. It also supports an Event Log that
can be viewed and downloaded through the CMB web service page.
1.36.2
Call Types Supported by the Capacity Max Bridge
The following call types are currently supported as bridged calls:
• Group Voice Calls (except All Calls)
• Off Air Call Set Up (OACSU) Private Voice Calls
• Emergency Voice Calls
• Capacity Max Emergency Alarm (sent as Emergency Alert on Connect Plus)
• Connect Plus Emergency Alert (sent as Emergency Alarm on Capacity Max)
1.36.3
Call Types Not Supported by the Capacity Max Bridge
Unsupported call types are not bridged beyond the originating system.
Any call type not listed as a supported call type is currently not supported. For example, Command and
Control Calls (Radio Check, Call Alert, and so on) and IP Data Calls (text messages, location updates,
and so on) are not currently supported as bridged calls.
Although some call types are not available as bridged calls, a subscriber radio operating in a particular
mode (for example, Connect Plus or Capacity Max) can still exercise the full feature set provided by its
native system.
NOTICE: For more information, see the Capacity Max Migration Guide.
106
MN003523A01-AC
System Planning
Chapter 2
System Planning
This section describes the Capacity Max System planning.
2.1
Capacity Max System Planning
This section summarizes a high level Capacity Max system planning, and identifies the major planning
steps to follow prior to ordering the system.
Overview
The following are some mandatory hardware and software requirements that must be fulfilled in order
to deploy a basic Capacity Max system. A Capacity Max system must have at least:
• A CMSS (Capacity Max System Server), with a licensed Trunking Controller
• One RF site with at least one trunking repeater, with a Capacity Max system license
• The Radio Management application to program the equipment
• The switches and routers to connect the equipment within the site or sites where the CMSS,
repeaters, and Radio Management are located
• Radios for the end users
Additional RF sites can be added for wider area operations and additional trunking repeaters can be
added at sites to support more users per site. Data Revert repeaters can be added to sites when
higher location update rates are required and/or to offload the data load from the trunking repeaters.
When more than one RF site is in the system, a Capacity Max Site license is required for each
additional site beyond the first. The additional Data Revert repeaters will also require Capacity Max
system license.
The Trunking Controller license types are the following:
• A multi-site Trunked Controller license, which supports single site and multi-site systems
• A single site only Trunking Controller license which supports single site systems
• A single site to multi-site Trunking Controller upgrade license which supports the expansion from a
single site only system to a multi-site system.
The System Advisor can be optionally added to monitor call activity and equipment status. MNIS VRC
Gateways and MNIS Data Gateways can be added to support wire-line voice and data applications.
Redundancy options are also available for both the hardware and the associated software licenses.
107
MN003523A01-AC
Chapter 2: System Planning
Figure 12: A Typical Capacity Max System
Capacity Max System Server (CMSS)
System
Trunking Voice Radio Data Battery
Advisor Management Management
Controller Gateway Gateway
Server
Switch
Router
IP Network
Router
Switch
Data
Trunking Trunking
Revert
Repeater Repeater
Repeater
2.1.1
High Level System Planning
The following sections describe a high level summary of how to go about planning for a Capacity Max
system.
The MOTOTRBO SDT (System Design Tools) can be used to calculate the number of CMSSs and all
Capacity Max licenses when a detailed system planning is required. Figure 9 shows the main user
interface to the System Design Tools for Capacity Max. The SDT for Capacity Max covers three main
areas as follows:
• Estimating the number of repeaters (trunked and data revert) needed at each site in the system
• Estimating the site link bandwidth needed for each site (RF or non-RF) in the system
• Determining the number of MNIS VRC Gateways needed in the system and estimating the number
of Talkpath licenses needed for each MNIS VRC Gateway
108
MN003523A01-AC
Figure 13: System Design Tool User Interface for Capacity Max
CONNECT PLUS Capacity Max System Capacity Estimator

Estimates the number of trunked and/or data revert repeaters a Capacity Max site requires for a
given number of active radios and traffic profile (voice and data usage).
CAPACITY MAX
Capacity Max Site Link Bandwidth Calculator

Determines the necessary bandwidth to link sites of a Capacity Max System.
LINKED CAPACITY PLUS
CAPACITY PLUS Capacity Max VRC Gateways and License Calculator

Determines the number of VRC gateways, talkpaths and licenses required by a Capacity Max
System configuration.
IP SITE CONNECT
CONVENTIONAL

A Capacity Max system requires at least one CMSS. A CMSS comes pre-installed with the Trunking
Controller, the MNIS VRC Gateway, and the System Advisor server. All components must be licensed
individually to function as described below.
Additional CMSS hardware may be purchased to support redundancy of the Trunking Controller, the
System Advisor server, or the MNIS VRC Gateway. Expansion CMSS hardware may be purchased to
increase the number of VRC Gateways in the system. The maximum number of CMSSs allowed in a
system is 40.
Note that for each RF site in the system, a Capacity Max Site License is required to enable it to attach
to the system. Each CMSS (primary or backup) that hosts the Trunking Controller requires the
appropriate number of Capacity Max Site Licenses.
Capacity Max Trunking Controller
A Capacity Max system requires at least one Trunking Controller, and can have a maximum of five.
When deployed in a private network the system supports up to four alternate Trunking Controllers.
Alternate Trunking Controllers may be placed at up to four different physical locations, different than
the locaton of the primary Trunking Controller.
When deployed in a public network with the HPE network transport solution, all Trunking Controllers
(primary and alternate) must reside at a physical location with an ADVPN hub router. The
recommended HPE router solution supports up to two ADVPN hubs, therefore all Trunking Controllers
must reside at no more than two physical locations. Trunking Controller placed at a physical location
without a ADVPN hub router will be unable to support multi-site calls when this Trunking Controller
becomes the active Trunking Controller.
The Trunking Controller software comes pre-installed on the Capacity Max System Server (CMSS) and
a Trunking Controller license is mandatory for the system to function
Additional Capacity Max Trunking Controller licenses for the backup CMSSs can be purchased for
redundancy.
109
MN003523A01-AC
MNIS VRC Gateway

A MNIS VRC Gateway license must be purchased, to support wire-line voice and command
applications such as voice consoles, voice recorders, or telephone gateways. The MNIS VRC Gateway
software comes pre-installed on the Capacity Max System Server (CMSS), but must have a license to
function.
The system supports up to 15 primary MNIS VRC Gateways and 15 redundant MNIS VRC Gateways.
Each MNIS VRC Gateway requires its own CMSS and its own license (whether primary or backup). A
VRC Gateway (primary and alternate) can reside on the same CMSS as a Trunking Controller (primary
and alternate). Additional MNIS VRC Gateways each require their own CMSS. Therefore the maximum
number of MNIS VRC Gateways licenses allowed in a given system is 30.
Choosing the Number of MNIS VRC Gateways
The number of MNIS VRC Gateways is dependent on the voice and radio command applications being
used. Voice and radio command applications can range from voice dispatch, to telephone interfaces, to
logging recorders and applications that discreetly listen to ongoing group and private calls. Each voice
and/or radio command application requires at least one VRC Gateway. Voice and radio command
applications typically have a server and client relationship where their servers are associated with a
single VRC Gateway. Some of the reasons for having multiple VRC Gateways are to allow more
talkpaths than a VRC Gateway on a given CMSS can support, and to support a VRC Gateway per
customer or application. Guidance is provided for selecting the appropriate number of VRC gateways.
See Number of VRC Gateways and Talkpaths Selection on page 145 for more details.
Sizing a VRC Gateway with the Required Number of Talkpaths
A VRC Gateway supports from 1 to 100 simultaneous external voice talkpaths. A talkpath is defined as
the sourcing and receiving of one voice call. Therefore, the number of voice talkpaths a VRC Gateway
requires is the number of calls that voice console can source and receive simultaneously. This is
similar to the number of trunked repeaters a site requires. Voice applications such as logging recorders
may have different needs. Command and control messaging like the radio commands does not require
talkpaths. See Number of VRC Gateways and Talkpaths Selection on page 145 for more details.
System Advisor
The System Advisor provides infrastructure equipment status, alarm and event reporting, and call
activity monitoring. The system supports up to five System Advisors. When more than two System
Advisor servers are deployed, the trunking controller selects two as active and the remaining System
Advisor servers become inactive.The System Advisor server comes pre-installed on the CMSS, but
require a license to function.
The System Advisor client runs from a web browser on any computer (that meets the minimum
hardware and software requirements) with a direct IP connection to the CMSS. Systems with less than
2500 repeaters can support 10 System Advisor Clients per System Advisor Server. Systems with more
than 2500 repeaters can support 5 System Advisor Clients per System Advisor Server. For more
details, see "Capacity Max Hardware Specifications" in Capacity Max Installation and Configuration
manual.
Although the System Advisor is not required, it is highly recommended to include it as part of the
Capacity Max System. For 3rd party applications, such as a manager-of-managers, to receive
infrastructure equipment status, alarms, and event reporting, the System Advisor NorthBound Interface
(NBI) license is needed.
Each CMSS running the System Advisor requires its own licenses (whether primary or backup).
Determining the Quantity and Location of RF and Non-RF Sites

A Capacity Max system supports up to 250 RF sites. The physical location of the RF sites must be
determined based on the coverage needs of the end users. The process of selecting locations differs if
creating a new system, replacing an existing system, or if the physical location of the sites is dictated
by the customer. Selection of the physical location of the non-RF sites (Trunking Controller, console,
110
MN003523A01-AC
data applications, and others) is important as well, and can often be driven by user access and the
user’s operational needs. The IP network configuration is impacted by the location of the non-RF
equipment in relation to the Trunking Controller and the RF sites.
RF coverage of a Capacity Max RF site is the same as previous MOTOTRBO architectures, which
simplifies planning upgrades from Other MOTOTRBO systems to Capacity Max.
In general, however, there are many factors that affect RF performance prediction and the more factors
that can be considered, the more accurate the prediction of coverage. Perhaps the most influential
factor is the selection of the RF propagation model and/or RF prediction software tools.
In order for an RF site to connect to the Capacity Max system, a Capacity Max Site License is required.
One Capacity Max Site License is included with the purchase of each Capacity Max Trunking
Controller license, therefore requiring one less Site License than the number of actual RF sites.
Capacity Max Site Licenses are required for CMSSs that host the primary Trunking Controller, and
those that host alternate Trunking Controllers, if used. Therefore a maximum of 250 Site licenses (249
purchased) is allowed for systems with a single Trunking Controller, and a maximum of 1250 Site
licenses (1249 purchased) is allowed for systems with a 4 backup Trunking Controllers.
Predicting the Number of Users and their Usage

In order to select the number of radio and repeaters appropriately, the first step is to determine the
number of users and attempt to predict their voice and data usage. The number of group, individual
and data calls per hour per user needs to be estimated, as well as the average call duration for group
and individual calls. The distribution of users across the RF sites is also important. Typical usage
profiles are identified and guidance is provided to determine if a customer is considered typical. See
Number of Users and Usage Prediction on page 122 for more details.
Capacity Max Subscribers

There are a wide range of different portable and mobile subscribers available, including low profile,
display and non-display models.
Capacity Max can be configured with up to 100,000 radios and 10,000 talkgroups. The number of
supported active radios is dependent on their usage profile. Generally, Capacity Max supports 45,000
active low usage users.
Each subscriber in the system must have a Capacity Max subscriber license. Capacity Max supports
two subscriber license types as follows:
• An Advantage license (enables Advantage Mode)
• A Full license (enables Advantage, Open System, and Open Radio Modes)
NOTICE: All licenses are not available in all regions and availability must be determined from
local ordering guides.
Subscriber Features
The following features are licensed per the subscriber, which vary by region and radio model; some
licenses are offered as standard on certain models. They can be utilized in Capacity Max and other
MOTOTRBO architectures.
• Transmit Interrupt (Voice Interrupt)
• Enhanced Privacy
• GPS Capable
• Enhanced GPS Capable
• Man-Down (CSA/ATEX) / Integrated Man-Down
• Data Services via Bluetooth
• Bluetooth Permanent Discovery Mode for Indoor Location
111
MN003523A01-AC
• Enhanced Option Board

• Text to Speech
• 280 Character Text Messaging
• SINC+
• WiFi
Capacity Max Trunking Repeaters

A Capacity Max system requires at least one trunking repeater per site, and currently supports up to 15
trunking repeaters per site. That is 30 logical channels, 29 trunked channels and 1 control channel.
Each repeater must have a Capacity Max repeater license. Capacity Max supports two subscriber
license types as follows:
• A Full license (enables Advantage, Open System, and Open Radio Modes)
NOTICE: All licenses are not available in all regions and availability must be determined from
local ordering guides.
Choosing the Number of Trunked Repeaters
The number of trunked repeaters at each site can be calculated based on the usage, the desired grade
of service, and estimated inter-site communication. Charts and calculators are available to help. See
Number of Users and Usage Prediction on page 122 and Number of Trunking Repeaters Selection in
Capacity Max on page 132 for more details.
Hardware Redundant Trunked Repeaters
Capacity Max already supports software redundancy in its design. For example if a control channel
repeater fails, the next control channel capable repeater at the site takes over. Loss of the traffic
channels means a lower grade of service, but the site still operates. A trunking repeater can optionally
have hardware redundancy as well. This is most useful for control channel capable repeaters and
especially useful if there is only one control channel capable repeater at a site. The redundant
repeater’s GPIO lines are wired to the primary repeaters GPIO lines and their RF input and outputs
require an RF switch if sharing the same transmit and receive antenna system. See "Repeater
Hardware Redundancy in Capacity Max" in the Capacity Max System Installation and Configuration
manual for more details.
Capacity Max Data Revert Repeaters

A Capacity Max system supports up to 6 Enhanced GPS (Scheduled) Data Revert repeaters. Data
Revert repeaters may be required, if the inbound data usage is too large and it cannot be supported on
the trunking repeaters. There are two types of Payloads, which are IP Data and High Efficiency Data
(CSBK). Guidance is provided to help select the appropriate configuration. See Capacity Max Data
Revert Channel on page 40 for a description.
Each Data Revert repeater must have a Capacity Max repeater license. Capacity Max supports two
license types as follows:
• A Full license (enables Advantage and Open System Modes)
Choosing the Number of Data Revert Repeaters
The number of Data Revert repeaters at each site can be calculated based on the number of users,
their GPS reporting rate, and the configuration of the Data Revert repeaters. Charts and calculators are
available to help. See Number of Data Revert Repeaters Selection on page 140 for more details.
Hardware Redundant Data Revert Repeaters
112
MN003523A01-AC
Data revert repeaters can optionally have hardware redundancy. The redundant repeater’s GPIO lines
are wired to the primary repeaters GPIO lines, and their RF input and outputs require an RF switch if
sharing the same transmit and receive antenna system. See "Repeater Hardware Redundancy in
Capacity Max" in the Capacity Max System Installation and Configuration manual for more details.
Acquiring Frequencies from your Frequency Coordinator

The frequency licensing process varies from region to region. Before the license process begins,
detailed information about the proposed radio system is usually required to be provided to the
frequency coordinator. The appropriate emissions designators and guidance on other information is
available to help. See Acquisition of New Frequencies (Region Specific) on page 174 for more details.
Selecting the Appropriate Network Equipment

Typically, one network router and one network switch is required for each site. A multiple switch
configuration per site is also available to remove the single point of trunking failure at a site. There are
recommended network routers and switches for Capacity Max, for which configuration and
troubleshooting support is provided. Functional requirements for selecting alternate routers and/or
switches are provided. See Network Components for Capacity Max IP Connectivity on page 149 for
more details.
Determining and Acquiring the IP Bandwidth required for each Site

The amount of uplink and downlink IP bandwidth required at a site is determined by the number of
simultaneous voice and data streams exiting and entering a site, and whether or not a CMSS (with
VRC Gateway and/or System Advisor), Data Gateway, and/or Radio Management is present at the
site. Charts and calculators are available to help. See IP Bandwidth Per Site Requirement for Capacity
Max on page 153 for more details.
Radio Management
A Capacity Max system requires Radio Management to configure the system. Radio Management can
be installed on any computer, that meets the minimum hardware and software requirements, with a
direct IP connection to the system. Radio Management consists of a four major components that can
be installed on the same or different computers, as follows:
• Radio Management Client : Edits and Manages Configuration Data
• Radio Management Server : Storage of Configurations
• Radio Management Device Programmer : Programs All Managed Devices
• Radio Management Job Processor: Processes Scheduled Jobs
It is recommended that one computer be initially purchased to support all four components. This
simplifies configuration and allows the configurations (the RM Server) to be stored with the system.
Additional computers can be added to support remote RM clients and remote RM device programmers
as the need arises. See "Hardware Specifications" in the Capacity Max System Installation and
Configuration manual for more details.
An MNIS Data Gateway is required to communicate to the radios over the air. See Capacity Max Radio
Management on page 67 and "Radio Management Configuration in Capacity Max" in the Capacity Max
System Installation and Configuration manual for more details.
Battery Management
A Capacity Max system can optionally support a Battery Management application to manage the health
of the radio’s batteries in the system. Battery Management can be installed on any computer, that
meets the minimum hardware and software requirements, with a direct IP connection to the system.
Battery Management consists of a three major components that can be installed on the same or
different computers, as follows:
113
MN003523A01-AC
• Battery Management Client : Main User Interface

• Battery Management Server : Storage of Configurations
• Battery Management Proxy : Communication to Radio System
It is recommended that one computer be initially purchased to support all three components. This
simplifies configuration and allows the battery data to be stored with the system. Additional computers
can be added to support remote clients as the need arises. An MNIS Data Gateway is required to
communicate to the radios over the air. For more details, see "Over The Air Battery Management
Configuration" in the Capacity Max System Installation and Configuration manual.
Choosing the Number of MNIS Data Gateways

A Capacity Max system supports up to 15 MNIS Data Gateways. Each one may have a paired
redundant MNIS Data Gateway. The number of needed Data Gateways is dependent on the data
applications being purchased. A data application requires at least one Data Gateway. Data
applications typically have a server and client relationship where their servers are associated with a
single or a paired (primary and redundant) Data Gateway. Data Gateway can reside on the same
computer as the data application server, or on its own dedicated computer.
The MNIS data gateway license supports:
• Single MNIS data gateway deployments
• Paired (primary and redundant) MNIS data gateway deployments
The MNIS data gateway license must be provisioned into the Trunking Controller. When more than one
Trunking Controller is deployed in a system, a separate license (single or paired) must be provisioned
into each Trunking Controller.
Since Capacity Max supports up to 5 Trunking Controllers, the maximum number of Data Gateways
licenses allowed in a given system is 75.
NOTICE: A Data Network Application Interface (NAI) license in each repeater is not required in
Capacity Max.
The MNIS data gateway must reside on a Windows OS server. When supporting MNIS data gateway
redundancy, both the primary and the redundant gateways of the pair must reside on their own
Windows OS server. In a redundancy deployment the application cannot reside on either of the
gateway servers. Deployment options for a single MNIS data gateway are:
• Application(s) and MNIS data gateway installed on same PC (Windows OS server)
• Application(s) and MNIS data gateway installed on different PCs
For more details, see Application Deployment Options with MNIS Data Gateways on page 141 .
Selecting the Appropriate Voice Console Applications

Several voice console application types from various manufacturers are supported in Capacity Max.
These range from voice dispatch, to telephone interfaces, to logging recorders. The appropriate voice
application that supports the customer’s desired features must be identified. Marketing brochures are
available to help with selection.
Selecting the Appropriate Data Applications

Numerous data application types from various manufacturers are supported in Capacity Max. These
range from text message applications to location applications. The appropriate data application that
supports the customer’s desired features must be identified. Marketing brochures and catalogs are
provided to help with selection.
114
MN003523A01-AC
2.2
Capacity Max Hardware Specifications
Relevant hardware specifications such as dimensions, power consumptions, operating temperature,
are provided for each piece of equipment in the system. Hardware specifications of software on non-
Motorola Solutions provided hardware.
Determination of how and where the equipment fits into the sites of the customer is important in
Capacity Max system installation. The relevant hardware specifications such as dimensions, power
consumptions, operating temperature, are provided for the following fixed end equipment:
• Capacity Max System Server (CMSS)
• Repeaters
• IP network equipment
Consider the Radio Frequency (RF) receiving and combining equipment and antenna space on the
tower.
NOTICE: Information for the RF receiving and combining equipment is not provided here.
Some of the system software can be installed on personal computer are not provided by Motorola
Solutions. The computer specifications for the following software are provided:
• Radio Management (Server, Client, Device Programmer, Tuner)
• Battery Management (Server, Client, Proxy)
• System Advisor Client
• ESU Client
2.2.1
Capacity Max System Server (CMSS) Hardware Specifications
The following is a summary of the CMSS hardware specifications.
Table 10: Summary for CMSS Hardware Specifications

Height 8.73 cm (3.44 in)
Width 44.54 cm (17.54 in)
Depth 73.02 cm (28.75 in)
Weight 23.6 kg (51.5 lb)
Operating Tem- 10°C to 35°C (50°F to 95°F) at sea level with an altitude derating of 1.0°C per
perature every 305 m (1.8°F per every 1000 ft) above sea level to a maximum of 3050
m (10,000 ft), no direct sustained sunlight. Maximum rate of change is
20°C/hr (36°F/hr). The upper limit and rate of change is limited by the type
and number of options installed. System performance during standard oper-
ating support may be reduced for an operation with a fan fault or above 30°C
(86°F).
Non-operating -30°C to 60°C (-22°F to 140°F) Maximum rate of change is 20°C/hr (36°F/hr).
Temperature
115
MN003523A01-AC
Operating Rela- Minimum to be the higher (more moisture) of -12°C (10.4°F) dew point or 8%
tive Humidity relative humidity. Maximum to be the lower (less moisture) of 24°C (75.2°F)
dew point or 90% relative humidity.
Operating Altitude 3050 m (10,000 feet). This value is limited by the type and number of options
installed. Maximum allowable altitude change rate is 457 m per minute (1500
feet per minute).
Non-operating Al- 9144 m (30,000 feet). Maximum allowable altitude change rate it 457 m per
titude minute (1500 feet per minute).
Operating Input 100–240 VAC
Voltage Range
AC Power 100–240 VAC, 50–60 Hz
Power Consump- • 800 W @ 120 V
tion
• 800 W @ 240 V
Input Current • 9.4 A @ 100 VAC

Drain
• 4.5 A @ 200 VAC
2.2.2
Repeater Hardware Specifications
The following is a summary of the various hardware specifications of repeaters.
Table 11: Hardware Specifications for MTR3000*

MTR3000
Height 5.25” (3 RU)
Width 19”
Depth 16.5”
Weight 40 lb/ 19 kg
Band VHF UHF
800/900
Frequency (MHz) 136–174 403–470 470–524
Tx Power (W) 100 100 100 100
AC (W) 410 340 380 390
Power Consumption
DC (W) 350 300 320 340
Operating Temperature (°C) -30/ +60
Table 12: Hardware Specifications for XPR8400*
XPR8400
Width 19”
Depth 11.7”
Weight 31 lb/ 14 kg
Band VHF UHF
116
MN003523A01-AC
Frequency (MHz) 136–174 403–470 450–512

Tx Power (W) 25 45 25 40 40
AC (W) 300 400 300 400 400
Power Consumption
DC (W) 100 160 100 160 160
Table 13: Hardware Specifications for XPR8380*
XPR8380
Width 19”
Depth 11.7”
Weight 31 lb/ 14 kg
Band 800/900
Frequency (MHz) 806–870 896–941
Tx Power (W) 35 30
AC (W) 400 400
Power Consumption
DC (W) 130 130
Table 14: Hardware Specifications for SLR5700*

SLR5700
Width 19”
Depth 14.6”
Weight 19 lb/ 8.6 kg
Band VHF UHF
Frequency (MHz) 136–174 400–470
Tx Power (W) 50 50
AC (W) 180 180
Power Consumption
DC (W) 130 130
NOTICE: * See the following respective Motorola Solutions sites to get the full hardware
specifications for each repeater per each region:
• NAG/LACR: http://businessonline.motorolasolutions.com
• EA: https://emeaonline.motorolasolutions.com
• APME: https://asiaonline.motorolasolutions.com
117
MN003523A01-AC
2.2.3
Hardware Specifications for Recommended IP Network Equipment
The following is a summary of the hardware specifications for the recommended IP Network
Equipment.
NOTICE: Refer to manufacturer for additional specifications for the following recommendations.
Table 15: Hardware Specifications for HP MSR2003 AC Router

The recommended router for IP Network Routers.
HP MSR2003 AC Router
Width 14.17”
Depth 11.81”
Weight 7.61 lb/ 3.45 kg
Operating Temperature 32°F to 113°F/ 0°C to 45°C
Maximum Power Rating (Watts) 54 W
AC Input Voltage 100 VAC to 240 VAC
AC Input Frequency 50 Hz to 60 Hz
NOTICE: Maximum power rating is the worst-case theoretical maximum numbers provided for
planning the infrastructure with 100% traffic, all ports plugged in, and all modules populated.
Table 16: Hardware Specifications for Cisco 2911 Router

The recommended router for IP Network Routers.
Cisco 2911 Router

Width 17.25”
Depth 12”
Weight 18 lb
@ 5,906 ft (1800 m) Altitude 32°F to 104°F/ 0°C
Operating Temperature
to 40°C
Typical Power (No Modules) (Watts) 50 W
Maximum Power with AC Power Supply 210 W
(Watts)
AC Input Voltage 100 VAC to 240 VAC (Auto Ranging)
DC Input Voltage 24 VDC to 60 VDC (Auto Ranging Positive or
Negative)
118
MN003523A01-AC
DC Input Current (Max) 8 A (24 V) 3.5 A (60 V)
Table 17: Hardware Specifications for HP Procurve 2530-24 Switch

The recommended router for IP Network Switches.
HP Procurve 2530-24 Switch

Width 17.4”
Depth 9.7”
Weight 5.7 lb/ 2.59 kg
Operating Temperature 32°F to 113°F/ 0°C to 45°C
Maximum Power Rating (Watts) 14.7 W
AC Input Voltage 100 VAC to 127 VAC/ 200 VAC to 240 VAC
NOTICE: Maximum power rating is the worst-case theoretical maximum numbers provided for
planning the infrastructure with fully loaded PoE (if equipped), 100% traffic, all ports plugged in,
and all modules populated.
Table 18: Hardware Specifications for Cisco 3650 Switch

The recommended router for IP Network Switches.
Cisco 3650 Switch
Width 17.5”
Depth 17.625”
Weight 24T - 15.15 lb (6.87 kg)24P - 16 lb (7.26 kg)
AC: -5°C to +45°C, up to 5000 ft (1500 m)DC: -5°C to
Operating Temperature
+45°C, up to 6000 ft (1800 m)
Power Consumption (Watts) - (No more 20T - 55.2124P - 64.18
than) - Weighted Average
AC Input Voltage 115 VAC to 240 VAC
DC Input Voltage -36 VDC to -72 VDC
DC Input Current 21 A to 10.5 A
NOTICE: Weight includes the chassis assembly as it is shipped: three fans, two Stackwise
adapters, and one power supply blank. The weight also includes the default power supply that
is shipped with the unit.
2.2.4
Computer Specifications of Application
Some of the system software must be installed on personal computers. The computer minimum
specifications for the following software applications are provided:
119
MN003523A01-AC
• Radio Management (Server, Client, Device Programmer, Tuner)

• Battery Management (Server, Client, Proxy)
• System Advisor Client
• ESU Client
All the listed software can coexist on the same computer. If the computer meets the sum of their
specifications, all the software can run simultaneously.
2.2.4.1
Radio Management Computer Specifications
The Radio Management (RM) software can be installed on any personal computer that meets the
following computer specifications.
Table 19: Recommendations for Radio Management Computer Specifications
Parameters Recommendations
Operating System Re- Standalone Radio Management Client (CPS), Standalone Radio
quirements Management Device Programmer, or Tuner
• Windows 8, Windows 8.1, 32-bit and 64-bit
• Windows 7 Home Premium or Professional (SP1 or higher) 32-bit
and 64-bit
Radio Management Client (CPS) with Radio Management Server

and Radio Management Device Programmer
• Windows 8, Windows 8.1, 32-bit and 64-bit
• Windows 7 Home Premium or Professional (SP1 or higher) 32-bit
and 64-bit
• Windows Server 2008 R2 SP1 32-bit and 64-bit
Recommended Hard- • Processor: 2 GHz dual core or higher Pentium grade processor
ware Requirements for
Small Fleets (<1000 • Memory: 4 GB RAM
Radios) • Aero capable graphics card with 128 MB graphics memory
• 50 GB free hard disk space on a 5400 RPM hard disk drive
• USB Port for radio communication
• DVD-ROM for software installation
NOTICE: Managing more radios (>1000) will require more
processing power in the server. See the Radio Management
Deployment Guide for more details on selecting the appropri-
ate hardware for the appropriate deployment and fleet size.
120
MN003523A01-AC
2.2.4.2
Battery Management Computer Specifications
The Battery Management software can be installed on any personal computer that meets the following
computer specifications.
Table 20: Recommendations for Battery Management Computer Specifications
Operating System Require- • Windows 7 x86 and x64
ments
• Windows 8 x86 and x64
• Windows Server 2003 x86 and x64
• Windows Server 2008 x86 and x64
• Windows Server 2008 R2 x64
Hardware Minimum Require- The IMPRESTM Battery Fleet Management application is installed
ments on a client/proxy computer or a server computer. The installation
package is the same for client and server computers, but the
hardware installation requirements are different for each.
Server Hardware Minimum • DVD drive
Requirements
NOTICE: If software downloaded from website, DVD
drive is not required.
• 1 GB of hard disk space
• 2 GB RAM
Client/Proxy Hardware Mini- • 1 Universal Serial Bus (USB) Port
mum Requirements
• DVD drive
NOTICE: If software downloaded from website, DVD
drive is not required.
• 200 MB of hard disk space
• 1 GB RAM
2.2.4.3
MNIS Data Gateway Computer Specifications
The Data Gateway (MNIS) software can be installed on any personal computer that meets the
Table 21: Recommendations for MNIS Data Gateway Computer Specifications
Operating System Requirements • Windows 8, Windows 8.1, 32-bit and 64-bit
• Windows 7 Home Premium or Professional (SP1 or higher)
32-bit and 64-bit
• Windows Server 2008 R2 SP1 32-bit and 64-bit
Hardware Minimum Require- • 5 GB of hard disk space

ments
121
MN003523A01-AC
• 1 GB RAM
NOTICE: Running multiple instances of MNIS on the
same hardware is not supported.
2.2.4.4
System Advisor Client Computer Specifications
The System Advisor Client software can be installed through a web browser on any personal computer
that meets the following computer specifications.
Table 22: Recommendations for System Advisor Client Computer Specifications
Operating System Require- • Windows 8, Windows 8.1, 32–bit and 64–bit
ments
• Windows 7 Home Premium or Professional (SP1 or higher)
32–bit and 64–bit
• Windows Server 2008 R2 SP1 32–bit and 64–bit
Hardware Minimum Require- • 2 GB of hard disk space

ments
• 2 GB RAM
Software Requirements • Recent versions of IE with at least IE v11, FireFox with at

least FireFox v20+, or Chrome with at least Chrome v43+
• Recent versions of Oracle Java 8 32–bit (v1.8.0_66 or great-
er)
2.2.4.5
ESU Client Computer Specifications
The ESU Client software is accessed through a web browser on any personal computer that meets the
Table 23: Recommendations for ESU Client Computer Specifications
Software Requirements A web browser that supports HTML5.
• Internet Explorer v10
• FireFox v40
• Chrome v43
2.3
Number of Users and Usage Prediction
This section describes the initial steps in determining the number of users, and attempt to predict their
voice and data usage, to size the system appropriately. The number of group, individual and data calls
per hour per user needs to be estimated, as well as the average call duration for group and individual
calls. The distribution of users throughout the RF sites is equally important. Typical usage profiles are
identified and guidance is provided to determine if a customer is considered typical.
122
MN003523A01-AC
Overview
Sizing the system correctly is an important part of planning for a Capacity Max system. The following
are the quantities, that often define the size of a system:
• Radios
• RF sites
• Trunked repeaters
• Data revert repeaters
• Voice gateway talk paths
The first step to determine these quantities is to predict the system usage, and the usage is made up of
the following:
• The number of simultaneously active radio users in the system and at each site
• The radio user’s call rate and call duration
• The average number of sites participating in a call
• The voice console call rate and call duration
• The number of outbound data application transmissions per hour
• The inbound periodic location transmissions per user
Sections below details the prediction of system usage. Once the values have been predicted, they can
be utilized in Number of Trunking Repeaters Selection in Capacity Max on page 132, Number of Data
Revert Repeaters Selection on page 140 and Number of VRC Gateways and Talkpaths Selection on
page 145. The information determined in these sections can be used as input to the Capacity Max
System Capacity Estimator that is part of MOTOTRBO System Design Tools.
2.3.1
Active Radio Users in the System Simultaneously
The number of users a system must support is the primary question, that drives the purchase of the
system’s radios. This number may be easy to acquire, if replacing a system, but if installing a new
system a series of customer interviews with pointed questions may be important.
The total number of radios purchased for a system does not mean all will be active at any given time. If
the organization operates in shifts, a percentage of the total number of radios may be active at any
particular shift. Even if a user operates in shifts, they may hand-off a single set of radios between
shifts, therefore the total number of radios may actually represent the number of simultaneously active
users.
It is a good idea to utilize the peak number of simultaneously active users. If the previous
communication system logged radio registrations, it may be an advantage to browse the logs, to
determine the peak number of registered users per day, per week, and during special events.
Future expansion should be also another consideration. If the customer knows that they will be
expanding their business in the near future, it might be wise to increase the estimated number of
simultaneously active users.
Predicting the Number of Simultaneously Active Radio Users at Each Site

Active users are spread over numerous sites, in a multi-site system. A site’s resources such as the
trunked repeaters, data revert repeaters, and others must be planned for each site; therefore it is
important to understand the distribution per site.
If users generally stay within the coverage of a single site, then it is straight forward to determine the
number of simultaneously active users for each site. The average number of simultaneously active
users at a site, can be simply found by dividing the total number of active users on the system by the
123
MN003523A01-AC
number of sites. This creates a balanced system, which is easiest since each site has identical
requirements.
NOTICE: If specific information is available about the user density of a particular site, for
example covering a town versus the countryside, then it may be necessary to load some sites
with more users than others.
If only a few users are mobile, that is moving between sites, they can be accounted for at each site
they may visit; therefore the maximum number of simultaneously active users at a site would be the
summation of the active stationary users and the active mobile users. It is unlikely that all mobile users
would end up at one site at the same time and impossible that they all show up at every site at the
same time, but the impact of adding resources at every site to accommodate the few may be
unimportant.
If most of the users of a system are mobile, prediction can become complicated.
The safest strategy is to presume that all the users in the system may end up at a single site at some
point, but sizing every site to support every radio in the system may be extremely wasteful since that
scenario is not very likely.
It is reasonable to think that in a system with highly mobile users that as many users leave a site as
there are users entering a site. Therefore the average number of simultaneously active users at a site
remains uniform across all sites. There may be some scenarios where this assumption is not true. For
example, there may be a centralized site that all users travel through at the beginning of a shift, or
there may be scenarios where a percentage of users from adjacent sites often enter a site without the
same number of users exiting a site. The extra number of users that roam to the site should be
accounted for in the maximum number of simultaneously active users at a site.
If the previous communication system logged radio registrations per site, it may be advantages to
browse the logs to determine the peak number of registered users per site, per day, per week, and
during special events. This will take the guess work out of determining the average and maximum
number of simultaneous active users at a site.
2.3.2
Radio User’s Call Rate and Call Duration Prediction
After the number of simultaneously active users per site is determined, the rate at which they transmit
must be predicted. The call rate is quantified by a number of calls per user per hour. There are three
call types to consider, which are the group calls, individual calls, and data messaging. An example of
data messaging is text messaging, although other types of asynchronous data can be handled
similarly. Periodic location data is considered in another section.
There are different call types supported in the system like the emergency, site call, radio check, and
other. It is assumed that these call types only occur occasionally and do not affect loading. If a user
utilizes an abnormally large amount of these call types, or if they utilize a specialized data application,
their impact on loading may wish to be considered.
There are three strategies to predict the user’s call rate, which are to interview the customer, review log
files, or use typical usage profiles.
Interview the Customer

NOTICE: Discuss with the customer about their usage. The amount of information acquired
from interviews varies.
Customers may not know the actual average call rate or call duration of their users, the average
number of text messages, group calls, or individual calls their users perform per hour; therefore extra
cautiousness is needed, when numbers are provided.
Some customers may only be able to identify the call type they use the most and little. For example,
some customers infrequently utilize individual calls, but some primarily utilize them. Some parts of their
124
MN003523A01-AC
organization primarily utilize text messaging to communicate, while others never use text messaging.
Some users may be known for their long detailed conversations on the radio system, while others
communicate using 10 codes. These approximations will help shape the usage profiles. It is
recommended to follow up, to determining the number of users utilizing these usage profiles and which
sites are they located at, approximately.
Review Log Files

Customers who review their call logs regularly, could provide a confident data related to their usages. If
the previous communication system call logs are available, acquire them and verify the peak call rate
for the peak hour of the peak day of the week, and during special events.
Cautiousness is necessary, when reviewing the logged data, as they must be read and interpreted
correctly. Logged data can often be misleading.
NOTICE: Be aware if transmissions, or calls consisting of numerous transmissions are logged,
as this can often distort the call rates and call durations.
Typical Usage Profiles

If historic system call logs are not available from the customer, typical usage profiles can be utilized.
There are two levels for each traffic; a typical low usage or light traffic user, and a typical high usage or
heavy traffic user. A medium user can easily be extrapolated. It is easiest if all users within a system
can be generalized to one of the existing profiles. The profiles must be adjusted, if no profile aligns with
the information acquired from the customer interviews.
The above profiles represent a quasi-transmission trunking model with a short voice call hangtime. On
average, group calls consists of 2 transmissions, and individual calls consists of 4 transmissions.
Setting call hangtime to zero (transmission trunking) will increase the call rate (multiplied by the
number of transmissions within a call), and lower the call duration (minus the call duration times the
number of transmissions with a call). Setting the call hangtime to a very large number (message
trunking), will increase the overall call duration.
When combining call rates and durations with other call rates and durations within a profile, the call
rates can be simply added up, but the call durations cannot simply be averaged, they must be
weighted by the call rate. For example, the profile’s weighted average call duration is calculated as
follows:
Profile
Weighted
( Talkgroup
x
Talkgroup
Call Rate Call Duration ) (
+
Individual
Call Rate
x
Individual
Call Duration) ( +
Data
Call Rate
x
Data
Call Duration )
=
Average
Call Duration Talkgroup Individual Data
+ +
Call Rate Call Rate Call Rate
Therefore, for the High Voice and Text User profile in the table above, the profile’s weighted average
call duration is as follows:
((2.7 x 10) + (0.3 x 20) + (2.5 x 1.5)) / (2.7+0.3+2.5) = 6.68 seconds
125
MN003523A01-AC
It is easiest if all users within a system can be generalized to one profile. For example if all 1200 users
at a site can all be considered to be ‘high voice and text’ users.
Through interviews, the customer may say some parts of their organization only utilize text messaging
to communicate, while others primarily utilize voice calls. They also may say some users infrequently
utilize individual calls, while some primarily utilize individual calls. General statements like this may
require user weighting between a few different altered profiles. Below is an example of how this might
be distributed. The customer would need to provide additional information on the quantities of users for
each profile.
When combining profiles the call rates are multiplied by the number of users utilizing that call rate and
then simply added up, but the call durations of the profiles cannot simply be averaged, they must be
weighted by the total call rate of each set of users. For example, the total weighted average call
duration is calculated as follows:
Total
Weighted
( Profile 1
x
Profile 2
Call Rate Call Duration ) (
+
Profile 2
x
Profile 2
Call Rate Call Duration ) (+
Profile n
x
Profile n
Call Rate Call Duration )
=
Average
Call Duration Profile 1 Profile 2 Profile n
+ +
Call Rate Call Rate Call Rate
Therefore, for all the profiles in the table above, the total weighted average call duration is as follows:
((750 x 1.5) + (2100 x 9.64) + (900 x 19)) / (750+2100+900) = 10.26 seconds
2.3.3
Average Number of Sites in a Call Prediction
The average number of sites participating in a call (sites per PTT) is an important factor in a multi-site
Capacity Max system. It affects how many calls initiated from a site are routed to how many other sites,
which affects the number of trunked resources at those sites and the IP link bandwidth.
The average number of sites participating in a call, minus one, is multiplied by the average number of
users at each site multiplied by their call rate to determine the incoming call rate and the outgoing call
rate.
Dynamic Talkgroup Affiliation

The average number of sites participating in a group call can be different based on customer usage. As
a user moves to a site and affiliates to a talkgroup, that site is included in the talkgroup call and the
number of sites participating in a call increases. The following chart shows the typical distribution of
sites per group call for systems with a typical number of sites.
126
MN003523A01-AC
Site / Call Probability

1 0.2238 Predicted Number of Sites per Call
2 0.1744
3 0.1360 0.30
4 0.1061 Weighted Average = 4.23 Sites / Call

5 0.0829
6 0.0648 0.20
Probability
7 0.0507
8 0.0398
9 0.0313 0.10
10 0.0247
11 0.0195
12 0.0155 0.00
13 0.0124 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
14 0.0100 Sites / Call
15 0.0081
If a system supports less than 15 sites, then the percentage associated with the larger number of sites
can be adjusted by distributing it across the remaining sites. This keeps the general trend as the
number of sites lowers, and lowers the weighted average of the distribution. Below are two charts with
the historical average sites per group call versus the number of sites in the system.
Figure 14: Number of RF Sites (1-20) vs. Historical Sites per Group Call
127
MN003523A01-AC
Figure 15: Number of RF Sites (20-250) vs. Historical Sites per Group Call
A customer’s unique usage will define the values, although this is considered typical. The average sites
per group call can be adjusted up if the customer makes an abnormally large number of wide area calls
or if their users within their talkgroups are spread out over an abnormally large number of sites. It is
important to understand that the number of sites per call is a distribution as shown above, and
fractional values for the weighted average are common.
The weighted average sites per call values above are an average over all sites. For example some
sites with voice consoles, may have an abnormally high sites per PTT value than other sites, but this is
normalized in the averaging. Sites with an abnormally high sites per PTT value may need to be
handled separately when calculating the required outbound IP bandwidth, but for choosing the number
of trunked repeaters, a system wide average is acceptable.
NOTICE: If the previous communication system call logs are available, acquire them and review
the average number of sites participating in each call.
The Impact of Static Talkgroup Affiliation on Sites per Call

Capacity Max allows statically configured talkgroup to site affiliations. Statically configured talkgroup to
site affiliation means that regardless if a user has dynamically affiliated a talkgroup to a site, the calls
for a talkgroup will always be routed to that site. If a large number of statically configured talkgroup to
site affiliations are utilized, this must be accounted for in the average sites per group call value. For
example if 80% of the talkgroups of a 15 site system have 7 sites statically configured, then the
average is probably not 4.23, but rather somewhere between 4.23 and 7. Consider using the weighted
average (0.8x7) + (0.2x4.23) /1, which is 6.4 average sites per PTT.
The Impact of Multiple Talkgroup Affiliation on the Number of Sites per Call
The average number of sites per call (sites/PTT) may increase as more radio users affiliate to mutiple
talkgroups (i.e. scan). As the number of users affiliated to a talkgroup increases, the number of sites
that need to be included in a call to service those users may need to increase. An increase to the sites
per call may increase the number of repeaters needed at each site to support the calls initiated at the
other sites.
128
MN003523A01-AC
Another way to visualize the impact is with a concept of virtual users. A system with 3000 users and
100 talkgroups has on average 30 users per talkgroup. If all 3000 users affiliated to 2 talkgroups, then
there would be an extra 3000 virtual users monitoring the 100 talkgroups since there are now on
average 60 users per talkgroup. But, those virtual users may only be affiliated to (i.e. scanning) a few
unique primary talkgroups (i.e. scanned talkgroups). Assume there are 10 unique scanned talkgroups.
Evenly spreading the 3000 virtual users over the 10 scanned talkgroups increases the number of users
in each of those 10 scanned talkgroups from 30 to 330, an increase of 1000%. Note that many times
not all users in a system are scanning, but also note that users can affiliate up to 7 talkgroups
It is difficult to predict the average increase to the number of sites required when a talkgroup size
increases dramatically. In this example it increases from 30 to 330. This is highly dependent on where
the scanning users are in reference to the original users. If the new scanning users are at the same
site(s) as the original users, then there is no increase to the number of sites per call. If the scanning
users are not at the same site(s) as the original users, they may all be at one other site. Then an
increase of 1 site per call occurs. If they are evenly distributed across every site within the system, then
the sites per call for the scanned talkgroups may equal the number of sites in the system.
If absolutely no additional topology or operational information is available about where the scanning
users are in reference to the original users, it is recommended that the following equation be utilized to
calculate the increase to the sites per group call based on the increase to the average users per
talkgroup:
0.434 x HistoricalSitesPerGroupCall x log10 (UsersPerScannedTG / UsersPerTG)
The historical data for sites per group call of a 10 site system is 3.77. Therefore, the above equation
would yield an increase to the sites per group call of 0.434 x 3.77 x log10(330/30) = 1.71.
The number of larger scanned talkgroups (10) represents a fraction (in this example 10%) of all the
overall number of talkgroups (100), therefore the increased sites per call only occurs a fraction of the
time and only impacts the overall average sites per call by a fraction.
For example, if you believe that the scanned talkgroups in the example above involve users from every
site, then the sites per group call of those scanned talkgroups may be 10 (not the 3.77 + 1.71 result of
the above equation). If weighted by 10%, the adjusted sites per group call would be 0.9x3.77 + 0.1x10
= 4.40. For medium call rates, this increase to the sites per group call (3.77 to 4.40) may not require an
additional repeater at each site. But as the number of scanning users increases, the number of
scanned talkgroups increases, and an increase to the sites per group call value may require additional
repeaters to retain an acceptable quality of service.
It is recommended to utilize the Capacity Estimator tool to calculate the number of repeaters required
per site for a particular scanning profile.
The Impact of Individual Calls on the Number of Sites per Call

The average number of sites per call (sites/PTT) decreases as the number of individual voice calls and
individual data calls increase in the system. This is because individual calls utilize either one or two
sites(which means 1.5 sites on average).
Typical systems have 90% group voice calls and 10% individual voice calls. For text messaging, it is
more typical to have 10% group text messages and 90% individual text messages. These percentages
will differ per customer. To find the overall percentage of individual voice and data calls in the system,
determine the ratio between the voice call rate and the data call rate.
The percent of individual voice and data calls in the system, and their corresponding 1.5 sites per call,
must then be weighted into the historical sites per group call, or into the adjusted sites per group call if
radios affiliate to multiple talkgroups.
For example, the historical data for sites per group call of a 10 site system is 3.77, and the adjusted
sites per group call for radios with multiple talkgroup affiliations may be 4.40. If a system has a medium
usage profile for voice (2 calls/user/hr) with 10% individual calls, and a medium usage profile for data
(1.5 calls/user/hr) with 90% individual text messages, then the percent of individual voice and data
calls in the system is (2×0.10+1.5×0.90) / (2+1.5) = 44%.
129
MN003523A01-AC
Therefore the sites per call adjusted for individual calls is 3.77 x (1 - 0.44) + 1.5 x 0.44, which equals
2.77. This new adjusted sites per call should be utilized to calculate the number of repeaters needed at
each site to support the calls initiated at the other sites.
It is recommended to utilize the Capacity Estimator tool to calculate the number of repeaters required
per site for a customer’s particular voice and data profiles.
2.3.4
Voice Console Call Rate and Call Duration Prediction
The number of outbound voice console calls, which are calls placed from the wireline console, is
another important factor in a Capacity Max system. It affects how many calls initiated from a console
are routed to the RF sites, which affects the number of trunked resources and the IP link bandwidth. It
also affects the number of voice gateways talkpaths necessary, which affects the number of voice
gateways.
It is important to not double count console calls. If the consoles simply respond to inbound radio
transmissions, then their load may have already been accounted for by the radio usage profiles; but if
the consoles initiate a large portion of the system calls, then they should be accounted for separately
since they do not affect the inbound control channel load.
It is recommended to interview the customer and review available log files, as predicting radio usage.
The interviews may provide general usage descriptions where as the log files will provide specifics.
The outgoing voice calls a voice console initiates per hour, has to be determined. A high use operator
may make one voice group call every 1 minute, whereas a low user operator may make a voice call
every 10 minutes. The number of outbound voice console calls can be different based on customer
usage. It is assumed that their call duration matches what was defined for the radios, but if that is not
the case, the voice console call duration should be increased or decreased as necessary.
The number of consoles multiplied by their call rate multiplied by the number of average sites per call,
provides the call rate the consoles place on the system. Then evenly dividing by the number of sites
results in the call rate a site receives from the consoles.
2.3.5
Outbound Data Application Transmissions per Hour Prediction
The impact from the number of outbound data application transmissions may need to be considered.
Outbound data application transmissions are routed to the RF sites, which affects the number of
trunked resources and the IP link bandwidth. The impact of these data transmissions is usually small,
but if an abnormally high rate of transmissions are occurring, it could impact the system performance.
If text messages are sent between the radios and a data application, rather than just radio to radio, the
outbound call rate should be accounted for. The inbound call rate should have already been accounted
for in previous sections within the radio user’s call rate and call duration. It is important to separate the
inbound and outbound call rate values since outbound data traffic does not impact the inbound control
channel capacity, but impacts the number of repeaters required and the outbound control channel
capacity.
The text message rate per hour per radio should be multiplied by the number of radios, to account for
the outbound responses from the data application.
NOTICE: Other data application messaging is different. Similar outbound traffic should be
included for any other data applications that send data to the radios.
2.3.6
Inbound Periodic Location Transmissions per User
The desired inbound periodic location transmission rate (outdoor or indoor) is configurable, and not
directly based on the action of radio users, unlike the other usages. This allows the amount of location
130
MN003523A01-AC
tracking load to be centrally managed by an administrator, by increasing or decreasing the requested

update transmission rate. High update rates can add a high load on a system, and should be managed
correctly.
• Firstly is to determine the number of users in the system, and ultimately at a site, which requires
location tracking. It is common that only a percentage of the users need to be tracked.
• Secondly is to determine the normal update rate for all the users. It is not always necessary to track
every user at the highest update rate at all the time, although it is supported. A five minute update
rate is usually sufficient for many users.
The update rate of individuals can be increased to the maximum of 7.5 seconds when necessary,
although a 30 second update rate is sufficient in most scenarios. A 7.5 second update rate is available
in some configurations. If a 7.5 second update is required; the high efficiency option, which utilizes
compression and data revert channels must be utilized. It is important to understand, the number of
users that may have high update rate at one particular time, as it determines the required appropriate
resources.
Location transmissions can be sent on the trunked channels, but the number of users and call rates
are limited. Data revert channels are available to support a higher number of users and a higher call
rate. A high efficiency option that utilizes compression is available to increase capacity, but not all GPS
parameters are provided. A scheduled revert channel is also available that optimizes the inbound
delivery of the location tracking which increases the call rate even higher.
Guidance is available to determine which configuration is necessary, once the customer’s desired
inbound periodic location transmission rate has been determined.
2.4
Transmission, Message and Quasi Transmission Trunking
This section describes the differences between Transmission Trunking, Message Trunking and Quasi
Transmission Trunking, the configurations, and how the selection can impact the number of trunked
repeaters required at a site
Overview of Voice Call Trunking Type and Configuration

Capacity Max voice calls can be configured to support the following Trunking Types:
Transmission Trunking
Every voice transmission starts with a control channel request for a trunked channel. The voice call
hangtime is set to 0 to enable Transmission Trunking.
Message Trunking
The first transmission of a voice call starts with a control channel request for a trunked channel, and all
subsequent transmissions during the duration of the voice call are initiated on the trunked channel. The
voice call hangtime is set large, where it can be multiples of 10 seconds, with Message Trunking.
Quasi Transmission Trunking
The first transmission of a voice call starts with a control channel request for a trunked channel, and all
subsequent transmissions during the duration of the voice call are initiated on the trunked channel. The
voice call hangtime is set small, like few seconds maximum, with Quasi Transmission Trunking.
2.4.1
Trunking Type Effects
Transmission trunking adds loading to inbound control channel, maximizes trunked channel efficiency
(for example, Erlangs), and comes with a risk of call continuity disruption. This results in the fewest
required trunked channels for a given load.
131
MN003523A01-AC
Message trunking minimizes loading on the inbound control channel, and minimizes risk to call
continuity disruption at the expense of decreasing trunked channel efficiency. The trunked channel
efficiency decreases, as the hangtime value is increased. This results in the most required trunked
channels for a given load.
NOTICE: A Capacity Max allows a group call initiator or either member of an individual call to
end the call during hangtime, to improve the trunked channel efficiency.
Quasi transmission trunking minimizes loading on the control channel. It settles between Transmission
and Message Trunking, in terms of call continuity disruption and trunked channel efficiency risk. The
required trunked channels for a given load will reside between Trunked and Message trunking
channels.
2.5
Number of Trunking Repeaters Selection in Capacity Max
This section describes how the number of trunked repeaters at each site can be calculated, based on
the predicted usage. Adequate information, charts and calculator are provided to verify, that the
loading does not exceed any of the system limitations.
Overview
There are three different strategies for choosing the appropriate number of trunking repeaters in a
trunking system, where some strategies are more accurate than others. The strategies involved are a
simple strategy, a better strategy, and the best strategy.
2.5.1
Strategy Types
The following are the strategies used, for choosing the number of trunking repeaters in a trunking
system:
Simple Strategy
A simple strategy is to use a long time general rule of thumb to determine the number of trunking
repeaters from the number of active users. The historical rule of thumb is the number of active users
divided by one hundred equals the number of repeaters.
NOTICE: This is a gross approximation and may or may not yield desirable results. The result
could be off by five repeaters, plus or minus.
The following figure shows two additional rule of thumbs; one for single site, and one for multi-site. A
rule of thumb early in the design process may be sufficient, but it is recommended to invest more time
sharpening the predictions prior to ordering the equipment.
132
MN003523A01-AC
Figure 16: Number of Repeaters Versus Active Users in Simple Strategy
Number of Repeaters versus Active Users

Rule of Thumb
15
14
13
12
11
Number of Repeaters
10
9
8
7
6
5 100 Active Users / Repeater
4
Single-Site Rule of Thumb
3
Multi-Site Rule of Thumb
2
1
0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000 5500 6000
Active Users
Better Strategy
A better strategy to calculate the number of trunking repeaters more accurately, is to predict the rate at
which calls are requested and the average call duration. Different call rates and call durations are
combined into typical user call profiles such as the high voice users, low voice users, and others, and
they are multiplied with the number of active users.
This can yield the total call rate and the average call duration for a site. Accompanied by a fixed grade
of service, and a fixed number of sites participating in a call (Sites per PTT), a more accurate number
of trunking repeaters can be calculated. This level of accuracy is sufficient for voice only systems
without voice consoles. The following figures shows how to determine the number of repeaters based
on the number of active users for a single-site system with high or low voice users, or multi-site system
with high or low voice users. See Number of Users and Usage Prediction on page 122 for more
information on the profile definitions.
133
MN003523A01-AC
Figure 17: Number of Repeaters Versus Active Users in Better Strategy
Number of Repeaters versus Active Users

<3% Grade of Service, 4.23 Sites / PTT)
15
14
13
12
11
Number of Repeaters
10
9
8
7
Single-Site Low Voice User
6
5 Single-Site High Voice User
4
Multi-Site Low Voice User
3
Multi-Site High Voice User
2
1
0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000 5500 6000
Active Users
Best Strategy
The best strategy is to account for all call rates and call durations for all call types such as the group
voice, individual voice, and data messages; entering the site from all inputs such as the inbound over
the air, inbound from other sites, inbound from voice consoles, and inbound from data applications.
The best strategy is to account for the uniqueness of a particular customer’s radio users, by creating
more accurate call profiles and combining them, rather than normalizing all radio users to one call
profile. Additionally, an acceptable grade of service can be used to calculate an accurate number of
trunking repeaters. This section and Number of Users and Usage Prediction on page 122 explains how
all these considerations are combined together to yield the total call rate and the average call duration.
The following figure summarizes the inputs and outputs of interest for a site.
Figure 18: The Inputs and Outputs of Interest for a Site
Inbound Voice
Over the Air
Inbound
Over the Air Inbound from
Inbound Data Other Sites
Over the Air
Inbound Inbound from
Site Over the Wire Voice Consoles
Outbound Inbound from
Over the Air Data Apps
In addition to finding the number of repeaters required per site, it is important to understand a few
system limitations: the maximum supported number of repeaters per site, the over the air call rate limit,
the outbound announcement call rate limit (total call rate for the site), and the over the air registration
limit. Staying under these limits can only be determined if all site inputs are considered.
134
MN003523A01-AC
2.5.2
Number of Users and their Usage Prediction
See Number of Users and Usage Prediction on page 122, for proper guidance in determining the
number of users and their usage. The following values should already been predicted:
• The number of simultaneously active radio users in the system and at each site
• The radio user’s call rate and call duration
• The average number of sites participating in a call
• The voice console call rate and call duration
• The number of outbound data application transmissions per hour
• The inbound periodic location transmissions per user.
These usage parameters are utilized to calculate the number of required trunked repeaters, and to
determine if any system limitations have been exceeded.
NOTICE: The accuracy of the output is highly dependent on the accuracy of the predicted
usage.
Configuration Tools (Use of Capacity Max System Capacity Estimator)

Configuration tools are available, that accept the number of users and their usage as inputs, and
provide the number of trunking repeaters required. The tool is more precise as it can use the exact
provided values, to calculate the number of trunking repeaters. The information determined in this
section can be used as input to the Capacity Max System Capacity Estimator that is part of
MOTOTRBO System Design Tools.
2.5.3
Number of Trunking Repeaters Calculation
The following describes the calculation of the Total Call Rate for the Site and the Average Weighted
Call Duration for the Site, when a configuration tool is unavailable. Figure 4 in Number of Required
Trunking Repeaters on page 138 illustrates these two values, together with a fixed grade of service, to
determine the number of repeaters required.
• Total Call Rate for the Site
The total call rate for the site is the over the air call rate plus the over the wire call rate.
Total Call Rate Over the Air Over the Wire

= +
for the Site Call Rate Call Rate
Over the Air Call Rate

The over the air call rate is the over the air voice call rate, plus the over the air data call rate. If the
voice and data call rates were already combined into one call rate, the combined call rate can simply
be multiplied by the number of simultaneous active radio users at a site.
Over the Air Over the Air Over the Air

= +
Call Rate Voice Call Rate Data Call Rate
Over the Air Voice Call Rate
135
MN003523A01-AC
The over the air voice call rate is the number of active radio users at a site, multiplied by the radio
user’s voice call rate. This should include the call rate of group calls and individual calls. The over the
air voice call rate will be required, when determining if the inbound registration limit is exceeded.
Over the Air # of Active Radio User

= x
Voice Call Rate Users Voice Call Rate
Over the Air Data Call Rate

The over the air data call rate is the number of active radio users at a site multiplied by the radio user’s
data call rate. This should include the call rate of text messaging, inbound location, or any other
inbound data.
The location call rate should be included, only if radios are sending their location on the trunked
channels. Location transmissions can be sent on the trunked channels, but call rate limitations will be
quickly surpassed. Data revert channels are available to support a higher number of users and a
higher call rate. See Number of Data Revert Repeaters Selection on page 140.
Over the Air # of Active Radio User

= x
Data Call Rate Users Data Call Rate
Over the Wire Call Rate

The over the wire call rate is the other sites call rate, plus the voice console call rate, plus the data
application call rate.
Over the Wire Other Sites Voice Console Data Application

= + +
Call Rate Call Rate Call Rate Call Rate
Other Sites Call Rate

The other sites call rate is the rate at which calls from other sites are routed to this site. The other sites
call rate is the over the air call rate (from above) multiplied by the average number of sites participating
in a call (Average Sites per Call) minus one. This assumes that the over the air call rate for this site is
representative of other sites.
Other Sites
Call Rate
=
Over the Air
Call Rate
x ( Average
Sites per Call
-1 )
Voice Console Call Rate
The voice console call rate is the rate at which calls from the voice consoles are routed to this site. The
voice console call rate is the number of voice consoles, multiplied the voice console call rate per voice
console, multiplied by the average number of sites per call, and then divided by the number of sites in
the system.
Voice Console
Number of Average
x Call Rate x
Voice Consoles Sites per Call
Voice Console = Per Voice Console
Call Rate Number of
Sites
136
MN003523A01-AC
Data Application Call Rate

The data application call rate is the number of outbound data application transmissions per hour. It
could be calculated as the number of outbound data messages sent to each radio multiplied by the
average number of active users at the site.
Data Application
Data Application # of Active
= x Call Rate
Call Rate Users
per User
• Average Weighted Call Duration for the Site

When combining durations with other durations, the call durations cannot simply be averaged; they
must be weighted by the rate at which they occur (that is, the call rate). This must occur for all call
rates that have unique call durations.
– Over the Air Voice Call Rate and Call Duration
– Over the Air Data Call Rate and Call Duration
– Other Sites Call Rate and Call Duration
– Voice Console Call Rate and Call Duration
– Data Application Call Rate and Call Duration
The following equation can be utilized to find the average weighted call duration of these parameters.
Average
Weighted =
( Call
Rate 1
x
Call
Duration 1 ) (
+
Call
Rate 2
x
Call
Duration 2 )(
+
Call
Rate n
x
Call
Duration n )
Call Duration Call Rate 1 + Call Rate 2 + Call Rate n
NOTICE: The other sites call duration is actually the average weighted call duration of the over
the air voice call rate and call duration and the over the air data call rate and call duration. Most
spreadsheet applications have a SUMPRODUCT function to help with the average weighted
call duration.
2.5.4
Grade of Service
The system grade of service is the percent of transmission requests (PTTs) that are immediately
serviced. A system with a 100% grade of service will experience no queuing. The blocking rate, like the
busy rate or queuing rate, is the percent of transmission requests (PTTs) that are queued because
there are no resources available. The queued radio user receives a talk permit tone, when a resource
is available. Therefore the blocking rate is, 1 - grade of service.
The blocking rate is important in calculating the number of repeaters at a site. The lower the blocking
rate, more repeaters are required to service a particular call rate and average call duration. The
number of repeaters at a site is typically calculated to achieve better than 3% blocking rate. Figure 4 is
created and illustrated using a 3% blocking rate.
System Blocking Rate
The system blocking rate is slightly different than the site blocking rate. In a multi-site system, where
multiple sites participate in a call, a resource must be available at each of the sites participating in the
call. The system blocking rate is calculated as follows:
137
MN003523A01-AC
(( ))
System Site 1 Site 2 Site n
Blocking = 1 -
Rate
1 - Blocking
Rate
) ( x 1 - Blocking
Rate
) ( x 1 - Blocking
Rate
If each site is designed for less than 3% blocking, and the average number of sites in a call is 4.23,
then the average system blocking would be better than 6.5%, 1 - (1-0.03)4.23. If a lower system
blocking rate is desired, a lower site blocking rate must be used in the design, or the number of sites
participating in a call, (that is, sites per PTT) must be lower.
2.5.5
Number of Required Trunking Repeaters
The number of repeaters can be determined, once the total call rate for the site and the average
weighted call duration for the site have been determined. The following figure is illustrates using a
grade of service for the site of 97%, that is 3% blocking rate.
Find the line that is closest to the calculated average weighted call duration and find where it crosses
the calculated total call rate for the site on the x-axis. The corresponding location on the y-axis is the
number of required repeaters.
Figure 19: Number of Required Repeaters Versus Call Rate versus Call Duration
Number of Required Repeaters versus Call Rate versus Call Duration
15
Average Weighted
Call Duration
14
for the Site
13 30 Second
Call Duration
12
20 Second
Call Duration
11
15 Second
Number of Repeaters
10 Call Duration
10 Second
9 Call Duration
8 7 Second
Call Duration
7 5 Second
Call Duration
6
4 Second
Call Duration
5
3 Second
4 Call Duration
2 Second
3 Call Duration
2 1 Second
Call Duration
1
0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 11000 12000 13000 14000 15000 16000 17000 18000 19000 20000
Total Call Rate for the Site (calls per hour)
2.5.6
System Limitations
There are few system limitations that user needs to be aware of, when determining the number of
trunked repeaters for a system, and their impact on the system can vary.
If any of these limitations are exceeded, the first step is to re-visit the predicted usage, and consider
switching from a high to low usage profile. Location update rates may need to be lowered or offset to
data revert repeaters. If usage is accurately captured, another nearby site may be required to offload
some of the active users. Site preference can be utilized to evenly distribute the users and talkgroups.
Maximum Supported Number of Repeaters per Site
138
MN003523A01-AC
Capacity Max supports up to 15 trunking repeaters per site and up to 6 data revert repeaters, thus the
total number of repeaters at the site cannot exceed 21.
Over the Air Call Rate Limit
The over the air call rate for the site should not exceed 12,000 cph. All inbound over the air call
requests must be received on the inbound control channel. The inbound control channel can only
receive 12,000 cph before performance begins to degrade. Once exceeded, the radio’s inbound
requests begin to collide with each other until their retries are exhausted. Their requests are never
received by the system and the radio provides a failure tone. At 16,000 cph 1% of all requests fail to
reach the system.
Outbound Announcement Call Rate Limit
The total call rate for the site should not exceed 20,000 cph, and it includes over the air call rate plus
over the wire call rate. Call grants must be announced to the radios over the air. The outbound control
channel can only announce 20,000 cph before performance begins to degrade. Once exceeded, the
time to respond to call requests decreases, and the time between announcing on-going calls
increases, which increases late entry time. At 25,000 cph the average time between on-going call
announcements increases past 2 seconds, and the average time to announce the second grant
increases past 500 milliseconds, which decreases reliability and therefore voice access time.
Inbound Registration Limit
The inbound registration rate should never exceed 17,000 registration per hour (rph) without
authentication enabled, and 14,000 rph with authentication enabled. The registration messages
include: power on registration, power off de-registration, user log in and log off, site affiliation
messaging, and talkgroup affiliation like the channel change. The registration messages are sent on
timeslot two of the active control channel repeater. Similar to the inbound control channel on time slot
one, the inbound registration channel on time slot two can only receive a certain number of
registrations per hour before performance begins to degrade. Once exceeded, the radio’s inbound
registrations begin to collide with each other, fail, retry, fail, retry, and so forth. Capacity Max system
has a mechanism to handle a large spike in registrations.
The maximum inbound registration rate (rph) lowers as more radio users affiliate to more talkgroups,
like the scan. Because a registration with multiple affiliations utilizes more bandwidth on the control
channel, fewer registrations can be made per hour. The sustainable registration rate (registration per
hour) versus the number of affiliated talkgroups is shown in the chart below.
Number of affiliated TGs Without Authentication With Authentication

1 17,000 rph 14,000 rph
2-3 11,000 rph 9,000 rph
4-7 9,000 rph 7,000 rph
It is difficult to predict the precise number of registration messages that occur on a system. Historically,
the number of registration messages that occur on a system is 2 times the over the air voice call rate
on the site.
Historical data shows that power on and off is a factor of 0.3, user log in and off is also a factor of 0.3,
talkgroup change is 0.2, and roaming is 1.2. A multiplying factor for all of them is 2. This aligns with
what is considered typical or normal user operation. It may need to be adjusted for some customers. If
only a percentage of users in a system roam, then a fraction of the 1.2 factor should be utilized. If user
login is not utilized in the system then the 0.3 factor need not be considered. If a portion of the users
only have one talkgroup, then the 0.2 talkgroup change factor can be lowered or removed completely.
For example, if all radio users monitor 2-3 talkgroups, and authorization is enabled in the system, then
9,000 registrations per hour are supported. If no one utilizes user login, 80% of the users have multiple
talkgroups, and only 50% of the users roam, then a factor of 0.3+0.3x0+0.2x0.8+1.2x0.5 = 1.06 can be
139
MN003523A01-AC
utilized, which corresponds to 8,491 over the air voice calls per hour per site. The site should not
exceed this number over the air voice calls per hour.
2.6
Number of Data Revert Repeaters Selection
This section describes how to determine if and what type of radio to server data should be sent on a
Enhanced GPS Revert Channel or a trunked channel and how to calculate the number of repeaters
needed at a site to support a predicted data load.
Overview of Sending Data on Trunked or Revert Channels

The control channel supports up to 200 inbound messages per minute at its site. Inbound messages
include requests from a radio for voice, text, location, and others. It also includes radio registration and
affiliation messages if non-Motorola Solutions radios are deployed on the system. If the overall load is
expected to be less than 200 inbound messages per minute, then all the data including radio to server
data, should be sent on the trunked channels. If the overall load is expected to exceed 200 inbound
messages per minute, then some if not all of the radio to server data should be sent on some type of
Revert Channel. The first type of data load to examine is location data. If location data exceeds 200
inbound messages per min, then the location data needs to be sent on EGPS Revert channels.
The information determined in this section can be used as input to the Capacity Max System Capacity
Estimator that is part of MOTOTRBO System Design Tools.
2.6.1
Enhanced GPS (EGPS) Revert Channel with IP Data
The Enhanced GPS (EGPS) Revert Channel with IP Data supports a large number of location updates
(both indoor and GNSS), with rich location parameters. Table 24 illustrates the number of updates per
minute a time slot supports for various Periodic Window Reservation and Window Size settings.
Table 24: The Number of Updates per Minute per Site

% Period- Radio to Server IP Data Messages per Minute per Site
ic Window
Window = Window = Window = Window = Window = Window =
Reserva-
5 6 7 8 9 10
tion
90 % 180 150 128 112 100 90
75 % 150 125 107 93 83 75
60 % 120 100 86 75 66 60
45 % 90 75 64 56 50 45
Number of EGPS Revert channels required at a site for IP Data use:

(Location Radios) * (average location updates / minute) / (appropriate chart value)
For example, 200 radios updating every 0.5 minutes with a Periodic Window Reservation of 75%
and a Window Size of 7.
(200 location radios) * (2 updates / minutes) / 107 = 3.74
For example, 4 channels (2 EGPS Revert repeaters) are necessary to support the data load. See
"Configuring Data Revert Channels" in the Capacity Max System Installation and Configuration
manual, for more detail on setting the Periodic Window Reservation. Third party developers can
provide the window size they require for their location server. The typical window size is 7 and the
typical channel loading is 75%.
140
MN003523A01-AC
2.6.2
Enhanced GPS (EGPS) Revert Channel with High Efficiency Data
The Enhanced GPS Revert Channel with High Efficiency Data supports a very large number of GNSS
location updates or Option Board data, but it supports a limited set of location parameters. Table 25
illustrates the number of updates per minute a time slot supports for various Periodic Window
Reservation and Window Size settings.
Table 25: The Number of Updates per Minute per Site

% Periodic Window Reser- Radio to Server High Efficiency Data Messages per Minute
vation per Site
Window = 1 Window = 2
90 % 900 450
75 % 750 375
60 % 600 300
45 % 450 225
Number of EGPS Revert channels required at a site for High Efficiency Data use:
(Location Radios) * (average location updates / minute) / (appropriate chart value)
For example, 425 radios updating every 0.25 minutes with a Periodic Window Reservation of 90 %
and a Window Size of 1.
(425 location radios) * (4 updates / minute ) / 900 = 1.89
For example, 2 channels (1 EGPS Revert repeater) are necessary to support the data load. See
"Configuring Data Revert Channels" in the Capacity Max System Installation and Configuration
manual, for more detail on setting the Periodic Window Reservation. A window size of 1 is used
when the server is connected through the MNIS data gateway, and a window size of 2 is used when
the server is connected through a wireless control station.
2.7
Application Deployment Options with MNIS Data Gateways
This section describes the deployment options for data applications and MNIS data gateways, and
explains when a Capacity Max system requires more than one MNIS data gateway.
2.7.1
Application Deployment Options
A system could have multiple MOTOTRBO data applications, such as Text Messaging Service (TMS),
Location Server Application, Over The Air Programming (OTAP), and any other special data
applications.
A MNIS Data Gateway can support all these applications. However, it is important to confirm with the
application vendor if any application restrictions apply.
A MNIS Data Gateway can be deployed in either of the following ways or a combination of both:
• MNIS Data Gateway and the data applications are deployed on the same computer.
• MNIS Data Gateway and the data applications are deployed on different computers.
Deploying the data applications and MNIS Data Gateway on the same computer is the simplest option.
However, the computer must meet the total performance requirement for MNIS Data Gateway and any
141
MN003523A01-AC
data applications deployed with it. For details, refer to the MNIS Data Gateway computer requirement
specification.
The data applications and MNIS Data Gateway can be deployed on different computers. The following
are the possible reasons for this practice:
• The computer does not meet the total performance requirement of the MNIS Data Gateway and the
data applications.
• The data application has restrictions of deployment with other applications.
• The data application is not a Windows application.
• To prevent unstable data application from interfering (such as operating system failure) with the
MNIS Data Gateway operation.
• MNIS data gateway redundancy.
The MNIS Data Gateway supports data message port forwarding to facilitate deployment of data
applications on separate computers, as shown in the following figure.
Figure 20: Deployment of Data Applications on Separate Computers
Location Packet Data
Port Forwarding Configuration in MNIS
UDP Port UDP Port Forward IP Port Type Source Destination

Type Number Address
UDP Port 4001 4001
Source 4001 172.16.0.3
IP 12.0.0.100 13.0.0.1
Source 4007 172.16.0.4
OTAP Device
IP Stack
Programmer
IP Stack
172.16.0.4 172.16.0.2
TMS MOTOTRBO OTA
SU
MNIS Capacity Max
MNIS App. ID = 1 System
Radio ID =
100
PC 3 PC 1
IP forwarding
Enabled
IP IP
Router
Location Packet Data after

Port forwarding
Port Type Source Destination

IP Stack
172.16.0.3
UDP Port 4001 4001 Location
IP 12.0.0.100 172.16.0.3
Routing path for routing data from
Location app to MNIS
Nw destination Gateway Interface
PC 2
12.0.0.0 172.16.0.2 172.16.0.3
13.0.0.0 172.16.0.2 172.16.0.3
14.0.0.0 172.16.0.2 172.16.0.3
The MNIS Data Gateway is configured to forward location and text data messages from the radios to
the computers with Location and Text applications respectively. The User Datagram Protocol (UDP)
port type configured is the source port because the radios standard data services ports are fixed (with
location = 4001 and Text = 4007).
The MNIS Data Gateway also allows selection of the destination port type. This option can be used for
non-standard data services such as third-party raw data. Configuration of port forwarding is not
required when the data application is deployed on the same computer as the MNIS Data Gateway.
Therefore, no port forwarding configuration is required for the OTAP Device Programmer. The
computers with the location and text applications require IP route configurations for routing messages
from the data applications to the computer with MNIS Data Gateway.
Figure 20: Deployment of Data Applications on Separate Computers on page 142 figure shows the
routes for data messages belonging to system CAI network IDs = 12, 13, 14.
142
MN003523A01-AC
If you deploy the data application and the MNIS data gateway on different computers, consider the
following:
• The hardware or operating system specification for the MNIS data gateway must be met. For more
details, see Capacity Max Hardware Specifications on page 115.
• In order to forward data messages from an application residing on a different PC to the MNIS data
gateway network interface, IP packet forwarding must be enabled in MNIS data gateway. This is
configured with Windows Routing and Remote Access Service. For more details, see "MNIS Data
Gateway Configuration in Capacity Max" in Capacity Max Installation and Configuration Manual
manual.
• Legacy data applications may require updates to support group data. Verify with the application.
• MOTOTRBO radios are assigned addresses from Class A IP address space with default network
IDs of 12, 13, 14. The talkgroups are assigned addresses from Multicast address space with default
network ID of 224. These addresses are not globally unique and conflict with IP address domains of
other enterprises. When applications are not deployed on the MNIS Data Gateway PC then the
network routing must be configured to route data messages from applications on external PCs to
the MNIS Data Gateway. To minimize network configuration it is recommended that the data
application and the MNIS Data Gateway PC are connected to the same subnet. The subnet must
not have any other PCs or devices that utilize radio IP addresses.
When an application must be remotely deployed, the following options should be considered:
- Select the application that supports a remote Proxy client, so the Proxy client can be deployed
with the MNIS Data Gateway and the application is deployed at the remote location. Data
messages between the application and the Proxy client occur over a custom interface that does
not expose the MOTOTRBO IP address to the network. Typically this removes the need to
configure network routing between the MNIS data gateway and the application.
- Deploy another MNIS Data Gateway at the remote location with the application.
- Establish a VPN connection between the remote application and the MNIS Data Gateway
subnet router.
Capacity Max supports redundant MNIS data gateways. The primary and the backup gateways are
deployed on separate Windows servers. The backup becomes active if the primary is unavailable.
Once the primary becomes available, it becomes active. Both the primary and backup gateways utilize
the same CAI IP and Radio ID addresses, which makes the gateway switchover transparent to the
radios. Date messages from radios continue to be received by the application no matter which gateway
is active.
To allow MSI applications to leverage the redundant data gateway configuration, a MNIS data gateway
Status Agent utility is deployed on the same server as the MSI application. The Status Agent monitors
which gateway is currently active and routes data messages to the active gateway. It is designed to be
used with MSI applications such as Radio Management Device Programmer and Battery Management.
The functionality of Status Agent with 3rd party applications is not verified.
For 3rd party applications, contact the vendor to determine if the application supports the redundant
data gateway configuration.
• If the application supports MNIS data gateway redundancy, follow the guidelines of the vendor.
• If the application does not support MNIS data gateway but other applications do, then it is
recommended that the non-supporting application utilize the primary data gateway. In this scenario
the applications supporting redundancy can utilize the backup gateway, while the applications not
143
MN003523A01-AC
supporting redundancy have the same availability as when a non-redundant data gateway is
deployed.
Table 26: Guidelines for Application Deployment with the MNIS Data Gateway.
Application Deployment Guidelines

MNIS Data Gateway MSI Applications Legacy 3rd party ap- 3rd party application
Deployment options plication without re- with redundant data
dundant data gate- gateway support
way support
Single MNIS data Deploy application on Follow vendor guide- Follow vendor guide-
gateway (same as data gateway server lines lines
Primary data gateway Or, if required, deploy
without backup gate- application on a sepa-
way deployment) rate server (explained
earlier in this section)
Primary and Backup Deploy application on For application with Follow vendor guide-
MNIS data gateway separate server with Primary data gate- lines
deployed in same the Status Agent. Ap- way, follow vendor
subnet plication operates guidelines.
when backup applica- Application cannot
tion takes over. communicate with ra-
dios when backup da-
Primary and Backup Deploy application on Follow vendor guide-
ta gateway takes over
MNIS data gateway data gateway server lines
deployed in different Or, if required, deploy
subnets application on a sepa-
rate server (explained
earlier in this section)
Application cannot
communicate with ra-
dios when backup da-
ta gateway takes over
NOTICE: Applications that support redundant MNIS data gateways typically require a Proxy
Agent to be deployed on both the primary and backup data gateway servers. Communications
between the application, which is deployed on a different server than either of the gateway
servers, and the gateway occurs through the Proxy Agent.
The Status Agent is installed on the MSI application server to support the redundant MNIS data
gateway configuration. Some important points as well as constraints are:
• For MSI applications, primary and backup data gateway servers must be deployed on the same
subnet.
• The Status Agent is only deployed on the MSI application server and not on either of the data
gateway servers.
• MSI application is not deployed on either of the data gateway servers.
- 3rd party applications must not be deployed on the same server as a MSI application or a Status
Agent.
- 3rd party applications can be deployed on a non-gateway server or the primary gateway server
For details on configuring the Status Agent and the redundant MNIS data gateway, see "MNIS Data
Gateway Configuration in Capacity Max" in Capacity Max Installation and Configuration Manual
manual.
144
MN003523A01-AC
While the MNIS Data Gateway (single primary data gateway or primary and backup data gateway
pairs) can support multiple data applications, only one instance of following types of application is
supported per MNIS Data Gateway.
• TMS application.
• Location Server application when high efficiency data format is used for location updates.
• XCMP Data application using high efficiency data format.
• Battery Management application.
• Telemetry application.
• Option board raw data application.
This is a restriction per type of the application. So, two TMS applications are not supported by a MNIS
Data Gateway, but a TMS application and a Telemetry application are supported by a MNIS Data
Gateway.
In a Capacity Max system multiple location applications that are utilizing high efficiency data format can
be deployed (with different data gateways). However, it should be noted that location updates (with
high efficiency data format) from the radio are sent to all the data gateways that are designated to
receive location with high efficiency data format. The MNIS data gateway can be configured with a
range of radio IDs, where received location data within the radio ID range is routed to the specified
Location Application. Location updates received by an MNIS data gateway, that is outside of the radio
ID range, are dropped. Additionally, the configured radio ID range is also applicable to high efficiency
XCMP data.
Capacity Max supports up to 15 MNIS Data Gateways. Each one may have a paired redundant MNIS
Data Gateway. Typically, multiple MNIS Data Gateways are required when two or more agencies are
sharing a Capacity Max system and they require data applications. When the number of such agencies
exceeds 15 then the application which can support remote clients should be considered. Such
applications should support data access, for the agencies, from a single central MNIS Data Gateway.
The MNIS Data Gateway supports MOTOTRBO systems such as the Single Site, IPSC, Capacity Plus
and Capacity Max. Redundant MNIS data gateways are only supported in Capacity Max. The MNIS
data gateway does not support multiple systems together. The MNIS Data Gateway operates in the
system mode based on the selected active configuration. For more information, see "MNIS Data
Gateway Configuration in Capacity Max" in the Capacity Max Installation and Configuration manual.
2.8
Number of VRC Gateways and Talkpaths Selection
This section provides guidelines to determine the number of VRC Gateway and number of active
talkpath licenses required by a Capacity Max system.
Overview
A Capacity Max system supports up to 15 VRC Gateways, where each VRC Gateway can have a
redundant VRC Gateway.
A Capacity Max system may require multiple VRC Gateways in the following scenarios:
• If a Capacity Max system is shared by a set of agencies, where each agency has its own set of
voice applications. In this scenario, a separate VRC Gateway is required for each agency because
either they are at different locations or they want independent deployment of their VRC Gateway
and applications.
• If the total capacity required by the system is greater than what is provided by one single VRC
Gateway.
145
MN003523A01-AC
2.8.1
VRC Gateway Capacity
The capacity of a VRC gateway is shown in the following table. If any of these capacities are exceeded
then one or more additional VRC gateways are required.
For example, if a system requires multiple voice applications and the total quantity is greater than ten
then one or more additional VRC gateways are required. Likewise, if the deployment calls for the
number of groups, radio IDs, radio ID ranges per telephone or recorder application to exceed the
gateway capacity then additional VRC gateways are required. If the number of talkpaths exceeds 100,
then additional VRC gateways are required.
Table 27: VRC Gateway Capacity

VRC Gateway
Capacity Parameter Assumptions
Max Capacity
Number of applications1 (cli- 10 See the following Note.
ents)
Number of Groups the appli- 1500 On average, three applications subscribe to
cations affiliates. same group.
Number of radio IDs the appli- 45000
cation registers.
Telephone or Recorder sub- 32 radio ID rang-
scribed radios es per application
2Number of calls (voice call 100 active talk- On average, a total of six sites (RF or VRC
session) that are active con- paths (or calls) Gateway sites) plus applications are partici-
currently and the application is pating in the call.
required to participate
Notes:
1Wireline voice applications (for example, voice dispatch, voice recorders, telephone gateway) and
non-voice wireline applications (only support radio commands) are generically referred to as
application in this section. Wireline voice dispatch applications normally have a client-server
architecture, where the dispatch position clients connect to the server. The application server connects
with the VRC Gateway. In this case, the server is counted as one application. A redundant server
application may be counted as one additional application when it remains connected with the VRC
gateway during stand-by (or inactive) mode. Likewise multiple instances of an application (or
application servers) connecting with the VRC gateway are counted as additional applications.
2When a VRC gateway has reached its talkpath license limit, and if a console at the VRC gateway is
starting a new call, then the call request is rejected; otherwise the call is setup but is not forwarded to
the voice application.
2.8.2
Active Talkpaths
A talkpath is the sourcing and receiving of one voice call to a VRC Gateway. When the number of on-
going voice calls handled by a VRC exceeds its talkpath limit, the system puts new voice calls that are
sourced or targeted to the VRC in queue. This section provides guidelines to estimate the number of
VRC gateway talkpaths required in the system. This number divided by the number of talkpaths a VRC
gateway supports is the number of VRC Gateways required to support those talkpaths. Exceeding any
of the capacities listed in the VRC Gateway Capacity section may require additional VRC gateways.
146
MN003523A01-AC
Ultimate Peak Number of Active Talkpaths

The maximum number of VRC gateway talkpaths that a system would ever possibly require is if every
trunked resource in the system was simultaneously utilized for a local site voice call and every one of
those calls was monitored by a voice application. This would essentially be the number of trunking
repeaters in the system multiplied by two, to account for each logical channel (that is, timeslot), and
then subtracting a control channel for each site. See Number of Trunking Repeaters Calculation on
page 135, for more information on calculating the number of trunking repeaters required per site and
therefore in the system.
Ultimate Peak Number of Active Talkpaths = ((Trunked Repeaters in the System x 2) - # of Sites).
Although, this is a highly unlikely scenario since multiple trunked resources at different sites commonly
participate in group and individual voice calls. In addition, not all group calls and individual calls are
monitored by voice applications. Since the number of talkpaths is licensed, a better estimation may be
desirable.
The first step is to make a reasonable estimation of the number of simultaneous voice calls that a
system may experience, and second is to determine how many of those voice calls are monitored by
voice applications.
Sites per Call

As the number of sites participating in a call increases, the number of simultaneous voice calls in a
system decreases, and therefore the number of required talkpaths decreases.
For example, if every call required resources at two sites, then the total number of simultaneous voice
calls in the system would be the number of traffic channels in the system (i.e. the Ultimate Peak
Number of Active Talkpaths) divided by two.
This means that the number of simultaneous voice calls for a call type can be calculated by dividing the
Ultimate Peak Number of Active Talkpaths by the average sites participating in a call of that type (i.e.
sites per call).
The number of sites participating in a call (i.e. sites per call) is a function of the call type. An individual
radio to radio call is 1 or 2 sites with an average of 1.5 sites per call. An individual radio to/from a
telephone or console call is 1 site per call.
The number of sites participating in a group call can be harder to predict. For guidance, see Number of
Users and Usage Prediction on page 122.
Percent Occurrence
Because these calls types do not occur equally, the number of simultaneous calls for each cannot
simply be added up, they must be weighted by their occurrence. Therefore the percentage that each
call type occurs on the system must be predicted:
• Group Call %
• Individual Radio to Radio Call %
• Individual Radio to/from Console or Telephone Call %
Typically there are 90% group calls, 9% individual radio to radio calls, and 1% individual radio to/from
console or telephone calls. These percentages must be adjusted for a particular customer’s usage.
The summed percentage of the three call types must be 100%.
Percent to/from Console or Logged

Because not all calls are routed to the VRC gateway, it is important to predict the percent of each call
type routed to the console or telephone or logged.
Typically 90% of group calls are either routed to the console or logged by a logging recorder. Individual
Radio to Radio calls are not usually routed to a console, but if logging is enabled, these calls may need
147
MN003523A01-AC
to be routed to a logging recorder. When logging individual radio to radio calls, typically 90% of them
are logged. By definition, 100% of the individual radio to/from console or telephone calls are either
routed to a console or telephone. These percentages must be adjusted for a particular customer’s
usage.
The talkpaths required for each call type can then be added up to acquire the total number of required
talkpaths. It is good practice to round up and add a few extra talkpaths in case the predictions turn out
to be under the actuals. This number divided by the number of talkpaths a VRC gateway supports is
the number of VRC Gateways required to support those talkpaths.
For example, if a system has 5 sites and 50 total trunking repeaters. The number of historical sites per
group call for a 5 site system (single talkgroup affiliation) is 2.65. Let us assume that there are 90%
group calls, 9% individual radio to radio calls, and 1% individual radio to/from console or telephone
calls. And let us assume that 90% of group calls are either routed to the console or logged by a logging
recorder, and 90% of the individual radio to radio calls are logged.
The ultimate peak number of active talkpaths is (50x2)-5 = 95. The talkpaths required for groups calls
is (95 / 2.65) x 0.9 x 0.9 = 29.04. The talkpaths required for individual radio to radio calls is (95 / 1.5) x
0.09 x 0.9 = 5.13. The talkpaths required for individual radio to/from console or telephone calls is (95 /
1) x 0.01 x 1 = 0.95. And the total number of required talkpaths is 29.04+5.13+0.95 = 35.12. We round
up to 36 talkpaths. Since 1 VRC Gateway supports 100 talkpaths, only one VRC Gateway is required.
Table 28: Talkpaths Required for each Call Type on page 148 table summarizes this example.
Table 28: Talkpaths Required for each Call Type
Simultane- Ultimate Sites per Percent Oc- Percent to/ Talkpaths

ous Calls Peak Num- Call curance from Voice Required
ber of Active Applica-
Talkpaths tion(Con-
sole, Log-
ger, Tele-
phone)
Groups Calls 95 2.65 90% 90% 29.04
Individual 95 1.5 9% 90% 5.13
Calls (Radio
to Radio)
Individual 95 1 1% 100% 0.95
Calls (Radio
to/from Con-
sole or Tele-
phone)
Total Talk- 35.12
paths:
2.8.3
Additional Notes on Talkpath Estimations
Additional considerations for estimating the number of talkpaths for a system are as follows:
• If multiple applications are affiliating to the same group, then the application should affiliate the
group from the same VRC gateway. If such an arrangement is not possible, then adjust upwards
the talkpaths by ‘n’ (n=1, 2, …) for every group voice call that is being routed to ‘n’ additional VRC
gateways.
• The number of group/individual voice calls should also include telephone calls.
• The number of talkgroups voice applications are affiliating should be known.
148
MN003523A01-AC
• Logging recorders affiliate to the group for recording the group voice call.
• Telephone applications affiliate to the group if it is initiating the group telephone call.
• If a logging recorder and a voice application are not using the same VRC gateway, then add the
number of simultaneous radios to/from the console individual calls to the number of talkpaths.
• This calculation does not account for any console to console communication that does not utilize a
trunked resource.
• It is not unusual to adjust the number of talkpaths upwards by (10-20%) to accommodate any
unforeseen peak scenarios or incorrect assumptions.
2.8.4
Talkpath Licenses and VRC Gateway
The system is configured to route calls (group, telephone and private calls to be recorded, allowed
sites for application radio IDs) to the VRC gateway. In case of multiple VRC gateways, the
configuration should be that the peak loading of a VRC gateway does not exceed the maximum
talkpath capacity of the VRC gateway. The talkpath license should be allocated to the VRC gateway
based on their call loading profile.
If a voice application is required to receive calls from multiple VRC gateways then contact the
application vendor to confirm if the application supports this feature. Confirm with the application
vendor the number of calls their application can support concurrently. The information determined in
this section can be used as input to the Capacity Max VRC Gateways and License Calculator that is
part of MOTOTRBO System Design Tools.
When redundant VRC gateways are not required:
• Number of VRC Gateway Licenses = Number of VRC ‘Primary’ Gateways.
• Number of talkpath License in each TC [primary and alternate(s)] = Talkpaths.
When each primary VRC gateway has a redundant VRC gateway:
• Number of VRC Gateway Licenses = Number of VRC ‘Primary’ Gateways x 2
• Number of Talkpath Licenses in each TC [primary and alternate(s)] = Talkpaths
2.9
Network Components for Capacity Max IP Connectivity
This section describes the requisite network components providing IP Connectivity for a Capacity Max
system.
Overview
A Capacity Max system comprises many devices that are located at one or more physical locations,
such as the Repeaters, Capacity Max System Servers (CMSS), MOTOTRBO Network Interface
Service (MNIS) Voice and Radio Command (VRC) Gateways, MNIS Data Gateways, Data Application
Servers, and Console Gateways. The system architecture relies upon IP Routing (OSI layer 3) and
Ethernet switching (OSI layer 2) to connect the devices. This section describes requisite network
components providing IP connectivity for a Capacity Max system.
2.9.1
Physical Location Requirements
Every physical location, including single site systems, in a Capacity Max system requires an Ethernet
switch and an IP router. Multi-site systems additionally require WAN links to provide IP connectivity
between physical locations.
149
MN003523A01-AC
Because Capacity Max systems manage many features and capabilities through software licensing, it
is highly recommended that all Capacity Max systems (including single-site systems) have at least a
temporary connection to a public Internet to be able to obtain the necessary licenses during installation
and future system upgrades and expansions.
If a connection to the public Internet is either not possible or not desirable (for example, due to
enhanced network security),then during license activation the device receiving the license activation
and/or Radio Management (RM) Client must be physically removed from the system and taken to a
location where a Radio Management Client can have access to the device receiving the license
activation, RM Server, and the public internet at the same time.
2.9.2
Ethernet Switch and IP Router Common Characteristics
The following table identifies both required and recommended characteristics common to Ethernet
switches and IP routers in a Capacity Max system..
Table 29: Ethernet Switch and IP Router Common Characteristics

Capability Descrip- Required May Be Needed When Needed?
tion
Fully Managed Yes When ability to re-
motely troubleshoot
or configure a net-
work device is de-
sired.
SNMPv3 Yes When System Advisor
is used.
IEEE 802.1q VLAN Yes When multiple sub-
Tagging nets are needed at a
physical location for
more than one RF
sites or more than
one gateways or any
combination of sites
and gateways at the
physical location.
Differentiated Serv- Yes When classifying and
ices (DiffServ) for managing network
Quality of Service traffic for quality of
(QoS) management service (QoS) is de-
sired.
150
MN003523A01-AC
2.9.3
Ethernet Switch Characteristics
The following table identifies both required and recommended characteristics for Ethernet switches in a
Table 30: Ethernet Switch Characteristics

tion
IEEE 802.3u Yes Always.
100BASE-TX Interfa-
ces (for connection to
Repeaters and Ca-
pacity Max System
Server)
Rapid Spanning Tree Yes When more than one
Protocol (RSTP, IEEE Ethernet switch
802.1w) isused at a physical
location.
IPv4 Yes Always.
Port Mirroring (SPAN Yes Always.
or RSPAN or RAP)
capability
Port Security Yes When increased net-
work security is de-
sired.
MAC port lockdown Yes When increased net-
work security is de-
sired.
Simple Network Time Yes When automatic syn-
Protocol (SNTP, RFC chronization of time of
4330) day across all net-
work devices is de-
sired.
2.9.4
IP Router Characteristics
The following table identifies both required and recommended characteristics for IP routers in a
Table 31: IP Router Characteristics

tion
IEEE 802.3u Yes Always.
100BASE-TX Interfa-
ces
2 Interfaces, minimum Yes Always.
151
MN003523A01-AC

tion
Rapid Spanning Tree Yes When more than one
Protocol (RSTP, IEEE Ethernet switch is
802.1w) used at a physical lo-
cation.
Open Shortest Path Yes When Dynamic Direct
First (OSPF, RFC Hub-Hub VPN Tun-
2328) neling such as
ADVPN or DMVPN is
used. Motorola Solu-
tions recommends us-
ing dynamic tunneling
in all Capacity Max
deployments for ease
of network configura-
tion.
IPv4 (LAN-side and Yes Always.
WAN-side)
Inter-VLAN Routing Yes When multiple sub-
Capability nets are needed at a
physical location.
Generic Routing En- Yes When VPN is used
capsulation(GRE, between physical lo-
RFC 2784) cations (required
when using public
ISP).
Dynamic Direct Hub- Yes When VPN is used
Hub VPN Tunneling between physical lo-
such as ADVPN cations (required
orDMVPN when using public
ISP).
IPsec (RFC 4301) Yes When VPN is used
between physical lo-
cations and increased
security is desired.
Network Time Proto- Yes When automatically
col (NTP, RFC 5905) synchronizing time of
day across all net-
work devices is de-
sired.
2.9.5
WAN Links (Site Links)
Internet Service Providers (ISP) provide a range of technologies, such as dial-up, Digital Subscriber
Line (DSL, typically Asymmetric DSL), Data Over Cable Service Interface Specification (DOCSIS)
cable modem, broadband wireless access, Integrated Services Digital Network (ISDN), Frame
Relay,satellite internet access, and so on, which can be used for Capacity Max WAN links. The
Capacity Max WAN links cannot be based on a dial-up connection (due to low link bandwidth) or
satellite internet access (due to large delay).
152
MN003523A01-AC
A site’s link bandwidth must be estimated, and once the estimated bandwidth is known, an appropriate
WAN link technology may be selected, and agreements can be negotiated with the WAN link provider
and appropriate equipment can be procured in accordance with the WAN provider’s recommendation.
To minimize configuration issues between the WAN equipment (for example, modem) and the network
equipment (for example, IP router) at a physical location, it is recommended that both the WAN
equipment and network equipment provide an IEEE 802.3u 100BASE-TX Interface set to auto-
negotiate speed, duplex, and crossover (Auto MDI-X). If auto-negotiate is not used, then the speed,
duplex, and crossover must be manually configured correctly in each device. If DOCSIS is used,
DOCSIS version 3.1, or newer, is recommended.
2.10
IP Bandwidth Per Site Requirement for Capacity Max
This section describes how to estimate link bandwidth requirements for a site, and covers both uplink
and downlink bandwidth requirements.
Overview
A physical location containing Capacity Max equipment must have IP connectivity through a wide area
network to other physical locations, or sites, in the system. An Internet Service Provider commonly
provides IP connectivity through a public internet, but private point-to-point links may provide
connectivity as well. It is important that a site link provides enough bandwidth to handle the expected
peak volume of data that will flow in either direction on the site link. “Uplink” refers to data flowing from
a site towards the other sites in a system and “downlink” refers to data flowing in the opposite direction.
Uplink and downlink bandwidth requirements are determined independently and are usually different.
Users calculate bandwidth requirements for each site link of a Capacity Max system independently.
The following figure is a reference model for determining link bandwidth requirements for a single
particular site belonging to a Capacity Max system. For purposes of this model, the Capacity Max
system has three components: a site (far left side of diagram), a site link whose bandwidth
requirements will be estimated, and the rest of the system, which includes the IP network and all other
sites.
Figure 21: Link Bandwidth Requirement Per Site
OTHER SITES
SITE
UPLINK
SITE SITE LINK IP NETWORK SITE

DOWNLINK
SITE
2.10.1
Factors Influencing the Required Bandwidth Amount on a Site Link
The following are factors that influence the amount of bandwidth required on a site link:
153
MN003523A01-AC
• The number of subscribers present at the site

• The number of subscribers at other sites
• The average number of other repeater sites associated with talkgroup calls
• The number of trunked repeaters present at the site
• The number of trunked repeaters at other sites
• The number and type of data revert repeaters present at the site
• The number of System Advisor server applications present at the site
• The number of System Advisor server applications at other sites
• The number of System Advisor client applications present at the site
• The number of System Advisor client applications at other sites
• The number of Radio Management server applications present at the site
• The number of Radio Management server applications at other sites
• The number of Radio Management client applications present at the site
• The number of Radio Management client applications at other sites
• The number of MNIS VRC Gateways (specifically talkpaths) present at the site
• The number of MNIS VRC Gateways (specifically talkpaths) at other sites
• The number of MNIS Data Gateways present at the site
• The number of MNIS Data Gateways at other sites
• The number of call monitoring applications present at the site
• The number of call monitoring applications at other sites
• The number of Trunking Controllers present at the site
Other factors that influence the amount of bandwidth required on a site link include the type of IP
tunneling used, as follows:
• “GRE Tunneling” is the minimum tunneling requirement when using a public internet to provide site
link connectivity and is used as a reference baseline for Capacity Max link bandwidth calculations.
“GRE Tunneling” provides a similar level of security as other MOTOTRBO systems, such as IP Site
Connect and Capacity Plus, and does not provide data integrity protection, sender authentication,
prevention of replay attacks, or confidentiality protection; however, when MOTOTRBO privacy
services are enabled in the radios and gateways, the MOTOTRBO privacy service does provide
confidentiality protection for end-user payload as packets flow across the public internet.
• “GRE Tunneling w/IPsec Authentication Header” may be used when data integrity protection,
sender authentication, and prevention of replay attacks are desired, but this tunneling mode
increases the link bandwidth requirements about 25% above the baseline “GRE Tunneling”
requirements. “GRE Tunneling w/IPsec Authentication Header” does not provide confidentiality
protection of packets as they flow across the public internet; however, when MOTOTRBO privacy
services are enabled in the radios and gateways, the MOTOTRBO privacy service does provide
confidentiality protection of end-user payload as packets flow across the public internet.
• “GRE Tunneling w/IPsec Encapsulating Security Payload” may be used when data integrity
protection, sender authentication, prevention of replay attack, and confidentiality protection is
desired and this tunneling mode increases the link bandwidth requirements about 30% above the
baseline “GRE Tunneling” requirements. “GRE Tunneling w/IPsec ESP” provides confidentiality
protection of both end-user payload and other Capacity Max system control information as packets
flow across the public internet regardless of whether MOTOTRBO privacy services are enabled in
subscribers or gateways.
154
MN003523A01-AC
• “No Tunneling” may be used only when private internets provide inter-site connectivity; however,
“GRE Tunneling” is still recommended when using a private internet so that the recommended
Capacity Max IP Plan may be easily used. The “No Tunneling” mode decreases the link bandwidth
requirements about 12% below the baseline “GRE Tunneling” requirements.
• “GRE Tunneling w/IPsec Encapsulating Security Payload and IPsec Authentication Header” is
rarely used in practice because of the increased overhead that Authentication Header would incur
for packets that are already adequately protected by Encapsulating Security Payload. This
tunneling mode increases the link bandwidth requirements about 40% above the baseline “GRE
Tunneling” requirements, when this combination is used.
The available tunneling modes are summarized in Tunneling Modes on page 155.
• The type of authentication and / or encryption algorithms used for IPsec also impact the amount of
bandwidth required on the site link.
• The table assumes that Authentication Header (AH) uses Secure Hash Algorithm (SHA) for the
Hash Message Authentication Code (HMAC), and Encapsulating Security Payload (ESP) uses
Triple-DES (or DES) for Confidentiality and Secure Hash Algorithm (SHA) for Hash Message
Authentication Code (HMAC).
This section provides a collection of graphs for common site and system configurations, for an initial
estimate of site link bandwidth requirements. For a more precise estimate, a site link bandwidth
estimation tool is available that allows each of the identified influencing items to be specified for a
specific link estimate.
2.10.2
Tunneling Modes
The available tunneling modes are summarized in the following table along with their capabilities and
link bandwidth requirements relative to the baseline.
Table 32: Capabilities and Link Bandwidth Requirements of Tunneling Modes
Tunnel Type Data Integri- Sender Au- Replay Pre- Confiden- Site Link
ty Protec- thentication vention tiality Pro- Bandwidth
tion tection Impact
No Tunneling No No No No Baseline -
12%
GRE Tunnel- No No No No Baseline
ing
GRE w/IPsec Yes Yes Yes No Baseline +
AH – As- 25%
sumes use of
Secure Hash
Algorithm
(SHA) Hash
Message Au-
thentication
Code
(HMAC)
GRE w/IPsec Yes Yes Yes Yes Baseline +
ESP – As- 30%
sumes use of
Triple-DES
155
MN003523A01-AC
Tunnel Type Data Integri- Sender Au- Replay Pre- Confiden- Site Link
ty Protec- thentication vention tiality Pro- Bandwidth
tion tection Impact
and SHA
HMAC
GRE w/IPsec Yes Yes Yes Yes Baseline +
AH and ESP 40%
2.10.3
Link Requirements
A good backend network needs to meet certian IP impairment requirements.
The following sections explain important IP impairments and their requirements.
• Delay/Latency on page 156
• Jitter on page 157
• Packet Loss on page 158
2.10.3.1
Delay/Latency
Backend network delay or latency through the network is characterized by the amount of time it takes
for a packet to traverse from a source device to a destination device.
Three types of delay are inherent in the backend network:
• Propagation delay – caused by the distance a signal must travel via light in fiber or as electrical
impulses in copper-based networks. A fiber network stretching halfway around the world (13,000
miles) induces a one-way delay of about 70 milliseconds.
• Serialization delay – the amount of time it takes for the source (for example, a repeater) to actually
place a packet byte by byte onto the backend network interface. Since in a Capacity Max system a
packet is sent one by one to all repeaters participating in a call; the serialization delay for the last
destination repeater is (# of participating sites in a call - 1) times the serialization delay for the first
destination repeater.
• Handling delay – the many types of delays introduced by the devices (for example, secure routers)
that forward the packet through the backend network. A significant component of the handling delay
is the queuing delay, which occurs when more packets are sent out to a network device than the
device can handle in a given interval.
In a Capacity Max system, for certain group calls, packets from a source site to a destination site may
go through another site in the system, known as a "replicator site". For details on packet replication/
distribution, see Centralized Distribution of Packets on page 171.
Propagation and handling delays depend on whether the "replicator site" is used for any talkgroup
voice/data call. It is recommended that the propagation and handling delays be measure (for example,
by pinging) as follows:
• If none of the sites in a system are configured for centralized distribution and if there are a total of
15 or fewer sites (RF sites plus primary VRC gateways) in the system, then measure the
propagation and handling delays (for example, by pinging) between any pair of devices/sites (for
example, repeaters/RF sites, trunked controllers, VRC gateways, data gateways, and so on)
In this example, Messaging Delay is equal to the maximum of the measured one way delay (Round
Trip Time, that is, ping time / 2) + 15 ms (worst case serialization delay).
156
MN003523A01-AC
• If one or more sites in a system are configured for centralized distribution or if there are more than
15 sites (RF sites plus primary VRC gateways) in the system, then measure the propagation and
handling delays (for example, by pinging):
1 from a repeater (RF site)/VRC gateway/data gateway to the Trunking Controller or "replicator
site"
2 from a Trunking Controller site or "replicator site" to another repeater (RF Site)/VRC gateway/
data gateway site
In this example, Messaging Delay is equal to the maximum measured one way delay from a source
to a 'replicator site' (Round Trip Time, that is, ping time measured from the source site / 2) +
maximum measured one way delay from a "replicator site" to a destination site (Round Trip Time,
that is, ping time measured from the "replicator site" / 2) + 15 ms (worst case serialization delay).
Radio Management (RM) allows users to set the Messaging Delay (that is, the sum of propagation
delay, serialization delay and handling delay) to be Normal_60 (60 ms), High_90 (90 ms) or High_150
(150 ms) in repeaters, radios and VRC Gateways.
• The default is Normal_60. If the measured messaging delay is less than 60 ms, then this setting
should be Normal_60.
• If the measured messaging delay is is more than 60 ms but less than 90 ms, then this setting
should be High_90.
• If the measured messaging delay is is more than 90 ms but less than 150 ms, then this setting
should be High_150. If the messaging delay is greater than 150 ms the Capacity Max system will
have occasion failures for arbitration, hangtime and data link layer acknowledgements. When using
High_150, the audio throughput delay will be larger then when the other settings can be selected.
For proper functioning of a Capacity Max system, all repeaters, radios and VRC gateways in the
system must have the same Messaging Delay setting.
2.10.3.2
Jitter
Jitter is the variation of packet inter-arrival time.
The source device – that is, a repeater or a MOTOTRBO Network Interface Service (MNIS) Voice and
Radio Command (VRC) Gateway – is expected to transmit voice/data packets at a regular interval, for
example, once every 60 ms for one channel. These packets can be delayed throughout the backend
network and may not arrive at the same regular interval at the destination device. The difference
between when the packet is expected and when it is actually received is called jitter.
To overcome the effect of jitter, the Capacity Max system employs a Jitter Buffer that is a function of
Messaging Delay. The following is the recommendation for maximum allowed network jitter.
• If none of the sites in a system are configured for centralized distribution and if there are a total of
15 or fewer sites (RF sites plus primary VRC gateways) in the system, then measure the
propagation and handling delays (for example, by pinging) between any pair of devices/sites (for
example, repeaters/RF sites, trunked controllers, VRC gateways, data gateways, and so on).
In this example, Maximum allowed network jitter = configured Messaging Delay - 15 ms
• If one or more site in a system is configured for centralized distribution or if there are more than 15
sites (RF sites plus primary VRC gateways) in the system, then measure the propagation and
handling delays (for example, by pinging):
1 from a repeater (RF site) or VRC gateway or data gateway to the Trunking Controller or
"replicator site"
2 from a Trunking Controller site or "replicator site" to another repeater (RF Site) or VRC gateway
or data gateway site
In this example:
157
MN003523A01-AC
- Measured jitter = maximum measured jitter in step 1 + maximum jitter measured in step 2
- Maximum measured jitter (allowed network jitter) <= configure 'Messaging Delay' - 15 ms
An actual network jitter beyond the recommended value degrades the audio quality and may result in
occasional loss of data calls.
2.10.3.3
Packet Loss
Packet loss in IP-based networks is both common and expected.
To transport voice/data bursts in a timely manner, the Capacity Max system cannot use a reliable
transport mechanism (that is confirming packets) and therefore it is necessary to minimize packet loss
when designing and selecting the backend network.
The Capacity Max system responds to periodic packet loss by either replaying a special packet in the
case of voice or the last received packet in the case of data.
• For voice, if six (6) consecutive packets do not arrive within 60 ms of the expected arrival time, the
call is ended.
• For data the repeater waits for the expected number of packets before ending the call.
For a Capacity Max system it is expected that the packet loss be less than 2.5%.
2.10.4
Site Link Bandwidth Requirements for Repeater Traffic
To estimate the required Site Link bandwidth for repeater traffic, all the charts illustrated in this section
assume the following, unless noted otherwise:
• No redundant repeaters at site
• One MOTOTRBO Network Interface Service (MNIS) Voice and Radio Command (VRC) Gateway
located in the system but at another site
• One MNIS Data Gateway located in the system but at another site
• One System Advisor server application located in the system but at another site
• One call monitoring application located in the system but at another site
• The number of data revert repeaters at a site varies automatically in accordance with the data revert
type and estimated subscriber load. See Capacity Max Data Revert Channel on page 40, for
recommendations on the number of GPS revert repeaters.
- Assume 100 subscribers per trunked channel which is also know as the timeslot, and all
subscribers use GPS.
- Enhanced GPS Revert Channel for IP Data:
+ 1 minute update period per subscriber.
+ Window size of seven, 90 % loaded, that is 128 updates per minute per timeslot.
- Enhanced GPS Revert Channel for High Efficiency Data:
+ 0.5 minute update period per subscriber.
+ Window size of one, 90 % loaded, that is 900 updates per minute per timeslot.
• The number of sites associated with a talkgroup call varies per the recommendations identified in
Number of Trunking Repeaters Selection in Capacity Max on page 132.
• GRE Tunneling is assumed. For other tunneling types, see Table 32: Capabilities and Link
Bandwidth Requirements of Tunneling Modes on page 155 to determine the amount by which to
scale the needed bandwidth.
158
MN003523A01-AC
Charts in this section correspond to GPS revert options: no GPS, Enhanced GPS, and High Efficiency
GPS. These charts assume that GRE Tunneling is being used. If a different tunneling mode is used,
then the value indicated in the chart needs to be adjusted by the amount shown in Tunneling Modes on
page 155.
2.10.5
GRE Tunneling, Uplink Bandwidth Requirement
The following charts correspond to different GPS revert options such as, no GPS, Enhanced GPS, and
High Efficiency GPS.
NOTICE: These charts assume that GRE Tunneling is being used. The value indicated in the
chart needs to be adjusted by the amount shown in Tunneling Modes on page 155, if a different
tunneling mode is used.
The following chart provides uplink bandwidth requirements at a site for a system with 15 or fewer
sites.
Figure 22: No GPS (15 Sites)
The following chart depicts the uplink bandwidth requirements for a system having up to 250 site. Note
that the uplink bandwidth does not grow exponentially as the number of sites is increased beyond 15.
This is because the average number of sites associated with a talkgroup call starts to plateau beyond
15 sites. For a more precise calculation of the required uplink bandwidth, refer to the System Design
Tools.
159
MN003523A01-AC
Figure 23: No GPS (250) Sites
The following chart provides uplink bandwidth requirements at a site for a system with 15 or fewer
sites.
Figure 24: Enhanced GPS Revert Channel for IP Data (15 sites)
The following chart depicts the uplink bandwidth requirements for a system having up to 250 site. For a
more precise calculation of the required uplink bandwidth, refer to the System Design Tools.
160
MN003523A01-AC
Figure 25: Enhanced GPS Revert Channel for IP Data (250 Sites)
Figure 26: Enhanced GPS Revert Channel for High Efficiency Data (15 sites)
161
MN003523A01-AC
Figure 27: Enhanced GPS Revert Channel for High Efficiency Data (250 sites)
Figure 28: Number of Revert Repeaters versus Number of Trunked Repeaters at Site
162
MN003523A01-AC
2.10.6
GRE Tunneling, Downlink Bandwidth Requirement
The downlink bandwidth requirements are not dependent upon the number of Enhanced GPS with IP
Data or Enhanced GPS with High Efficiency Data repeaters located at a site.
The following table specifies the downlink bandwidth required for a site with a given number of trunked
repeaters. The downlink bandwidth roughly follows the equation 30.2 kbps x
NumberOfTrunkedChannels + 12 kbps, and following all of the assumptions stated in GRE Tunneling,
Uplink Bandwidth Requirement on page 159. Remember that the number of trunked channels is equal
to one less than the number of trunked repeaters.
Table 33: The Downlink Bandwidth Required for a Site

Number of Trunked Repeaters at Site Downlink Bandwidth (Mbps)
1 0.039
2 0.099
3 0.159
4 0.220
5 0.280
6 0.340
7 0.400
8 0.461
9 0.521
10 0.581
11 0.642
12 0.702
13 0.762
14 0.823
15 0.883
2.10.7
Bandwidth Requirements Estimation and Examples
The information determined in this section can be used as input to the Capacity Max Site Link
Calculator that is part of MOTOTRBO System Design Tools.
Estimating Site Link Bandwidth Requirements for Sites Having a Call Monitoring Application
When a call monitoring application (for example, System Advisor server) is located at a site, the
downlink bandwidth requirements at that site should be increased by the amounts indicated in the
following chart per call monitoring application instance as a function of the total number of trunked
repeaters and sites in the system. Two charts are provides, one for system with up to 15 sites and one
for systems up to 100 sites and 500 repeaters. For more precise downlink bandwidth calculations, see
the System Design Tool.
163
MN003523A01-AC
Figure 29: Downlink Bandwidth for Site with Call Monitoring Application
The downlink bandwidth requirements at that site should be further increased by the amounts indicated
in the following chart per call monitoring application instance as a function of the total number of data
revert repeaters in the system.
164
MN003523A01-AC
Downlink bandwidth increases (in kbps) roughly by 0.683 * Number of data revert repeaters in the
system. This equation is applicable to any number of data revert repeaters in the system. For example:
• for a system with 40 data revert repeaters, additional downlink bandwidth = 0.683 * 40 ≈ 27.32 kbps
• for a system with 600 data revert repeaters, additional downlink bandwidth = 0.683 * 600 ≈ 410
kbps
• For a more precise bandwidth calculation, refer to the System Design Tool.
NOTICE: When a call monitoring application (for example, System Advisor server) is located at
a site, the uplink bandwidth requirements do not need to be adjusted.
Estimating Site Link Bandwidth Requirements for Sites Having Radio Management Clients
When a Radio Management client is located at a site that does not have a Radio Management server,
the downlink and uplink bandwidth requirements at that site should be increased by the following
amounts per Radio Management client instance:
• GRE tunneling: 0.055 Mbps (55 kbps)
Estimating Site Link Bandwidth Requirements for Sites Having Radio Management Servers
When a Radio Management server is located at a site and Radio Management clients are located at
other sites, the downlink and uplink bandwidth requirements at the site with the Radio Management
server should be increased by the following amounts per remote Radio Management client instance:
Estimating Site Link Bandwidth Requirements SSC Router is Present in the System
System Advisors are connected to the SSC (Solution Support Center) for fault management through a
SSC router. For more details. see "Configuration of SSC Router Connection in Transport Network" in
165
MN003523A01-AC
Capacity Max Installation and Configuration manual. In a system configuration that has multiple
System Advisors at Multiple Capacity Max sites, the SSC router is installed only in one of the System
Advisor sites. All the other System Advisors forward the SSC traps to the SSC router first, then to the
SSC which generates additional network traffic. To prevent impacts to the Capacity Max radio system
audio streams, additional 0.32 Mbps (320 kbps) bandwidth should be allocated between any SA site
and the site that hosts the SSC router.
Estimating Trunked Controller Link Bandwidth Requirements

When one or more trunked controllers are located at a site, the downlink bandwidth requirements at
that site should be increased by the amounts indicated in the following chart as a function of the total
number of trunked repeaters in the system. Two charts are provided, one for a system with 225
trunked repeaters and another with 500 trunked repeaters. For more precise downlink bandwidth
calculations, refer to the System Design Tool.
Figure 32: Downlink Bandwidth at Site with Trunked Controller
Downlink Bandwidth Required at Site with Trunk Controller
(GRE Tunneling is Assumed)
700.0
600.0
Downlink Bandwidth Required (kbps)
500.0
400.0
300.0
200.0
100.0
0.0
0 25 50 75 100 125 150 175 200 225
Total Number of Trunked Repeaters in System
When one or more trunked controllers are located at a site, the uplink bandwidth requirements at that
site should be increased by the amounts indicated in the following chart as a function of the total
number of trunked repeaters and sites in the system.
166
MN003523A01-AC
Figure 33: Uplink Bandwidth at Site with Trunked Controller
167
MN003523A01-AC
Figure 34: Uplink Bandwidth at Site with Trunked Controller
NOTICE: The above charts describing uplink and downlink bandwidth for the trunked controller
assume there is one MNIS VRC Gateway, one MNIS Data Gateway, and one System Advisor
server in the system.
Estimating Site Link Bandwidth Requirements for Sites Having System Advisor Clients
When a System Advisor client is located at a site that does not have a System Advisor server, the
downlink and uplink bandwidth requirements at that site should be increased by the following amounts
per System Advisor client instance:
Estimating Site Link Bandwidth Requirements for Sites Having System Advisor Servers
When a System Advisor server is located at a site and System Advisor clients are located at other
sites, the downlink and uplink bandwidth requirements at the site with the System Advisor server
should be increased by the following amounts per remote System Advisor client instance:
NOTICE: If the System Advisor server is receiving call monitoring traffic, bandwidth for the call
monitoring traffic must be included. See the previous section on Estimating Site Link Bandwidth
Requirements for Sites Having a Call Monitoring Application.
Estimating MNIS VRC Gateway Link Bandwidth Requirements
When a MNIS VRC Gateway is located at a site, that site’s downlink bandwidth requirements should
be increased by the following amounts as a function of total number MNIS VRC gateway talkpaths at a
site.
168
MN003523A01-AC
Figure 35: Downlink Bandwidth at Site with VRC Gateway(s)

Downlink Bandwidth Required at Site with VRC Gateway(s)
14000
12000
Downlink Bandwidth Required (kbps)
10000
8000
6000
4000
2000
0
0 50 100 150 200 250 300 350 400 450 500
Total Number of Talkpaths at Site
When a MNIS VRCGateway is located at a site, that site’s uplink bandwidth requirements should be
increased by the following amounts as a function of total number MNIS VRC Gateway talkpaths at a
site and the number of sites participating in a call.
Figure 36: Uplink Bandwidth at Site with VRC Gateway(s)
Uplink Bandwidth Required at Site with VRC Gateway(s)
20000.0
Sites in
System Average
18000.0
1 1.0
2 1.5
160000 3 1.9 15 Sites per Call
4 2.3 14 Sites per Call
5 2.6
Uplink Bandwidth Required (kbps)
13 Sites per Call

14000.0 6 3.0
12 Sites per Call
7 3.2
120000 9 3.6 10 Sites per Call
100000
12 4.0
7 Sites per Call
13 4.0
80000 5 Sites per Call
15 4.2
4 Sites per Call
60000 3 Sites per Call

2 Sites per Call
1 Sites per Call
40000
20000
0.0
0 50 100 150 200 250 300 350 400 450 500
Total Number of Talkpaths at Site
169
MN003523A01-AC
NOTICE: The above charts describing uplink and downlink bandwidth for the MNIS VRC
Gateways assume there is one call monitoring application in the system.
Estimating MNIS Data Gateway Link Bandwidth Requirements
When a an MNIS Data Gateway is located at a site, that site’s uplink and downlink bandwidth
requirements should be increased based on the amount of anticipated traffic load generated by the
data application(s) being used. When computing the anticipated traffic load, it is useful to estimate the
size of the data message, in bytes, and if VPN tunneling is being used in the system increase the size
of the message by an amount as indicated in the following table.
Tunnel Type Site Link Bandwidth Impact

No Tunneling + 0 bytes per message
GRE Tunneling + 24 bytes per message
GRE w/IPsec AH3 + 68 bytes per message
GRE w/IPsec ESP4 + 81 bytes per message
GRE w/IPsec AH and ESP + 105 bytes per message
3 IPsec AH Assumes use of Secure Hash Algorithm (SHA) Hash Message Authentication Code
(HMAC)
4 IPsec ESP Assumes use of Triple-DES and Secure Hash Algorithm (SHA) Hash Message Au-
thentication Code (HMAC)
The resulting message size is then multiplied by an estimate of the number of messages per hour
generated by the data application. Finally, the result is converted to bits per second by multiplying by 8
bits per byte and then dividing by 3600 seconds per hour.
Examples
Using the guidance provided above, several examples are provided herein. The assumptions used in
these examples match the assumptions stated above except where noted to be different.
Example: A repeater site having 8 repeaters, no GPS reverts repeaters, in a 5 site system,
and using GRE tunneling.
Uplink: 1.033 Mbps (read directly from the chart)
Downlink: 0.463 Mbps (read directly from the table)
Example: A repeater site having 6 repeaters, 5 Enhanced GPS revert repeaters, in an 8 site
system, and using GRE tunneling.
Uplink: 1.028 Mbps (read directly from the chart)
Downlink: 0.343 Mbps (read directly from the table)
Example: The system of example 2 with a System Advisor client present at the site.
Uplink: 1.028 Mbps (read directly from the chart) + 0.055 Mbps = 1.083 Mbps
Downlink: 0.343 Mbps (read directly from the table) + 0.055 Mbps = 0.398 Mbps
Example: The system of example 3 with GRE w/IPsec AH tunneling.

Uplink: [1.028 Mbps (read directly from the chart) + 0.055 Mbps] x 1.25 = 1.3569 Mbps
Downlink: [0.343 Mbps (read directly from the table) + 0.055 Mbps] x 1.25 = 0.500 Mbps
170
MN003523A01-AC
2.10.8
Centralized Distribution of Packets
There may be one or more sites (for example, RF sites) in a system where the available uplink
bandwidth is less than the estimated uplink bandwidth requirement. These ‘uplink bandwidth limited
sites’ do not have the capacity to deliver/distribute packets (voice and data) to all other participating
sites while meeting the delay and jitter requirements. This may result in occasional audio holes, lost
data calls, and so on.
One solution to this problem is to move the packet (voice / data) distribution responsibility to another
site in the system, a "replicator site". Uplink bandwidth limited sites should be configured for
‘Centralized Distribution’ using Radio Management tool. Each repeater at a site configured for
“Centralized Distribution’ sends its packets to the "replicator site". The "replicator site" in turn replicates
the packets to all other participating sites. Estimated downlink bandwidth (calculated as per the
guidelines mentioned in this section) and minimum uplink bandwidth (as mentioned in this section)
must be provided at a site that is configured for Centralized Distribution.
In a system having more than 15 sites (RF sites + primary VRC gateways), it is possible that some talk
group calls have more than 15 participating sites. For such talk group calls, a repeater may not have
enough processing power to guarantee distribution of packets at a desired rate. This may result in
occasional audio holes, lost data calls, and so on.
If a talkgroup has more than 15 participating sites, then the system automatically uses a"replicator site"
for that call, whether or not any of the participating sites is configured for Centralized Distribution.
Instead of sending the voice / data stream to all participating repeaters / VRC gateways, a repeater /
VRC Gateway sends the voice / data stream to a replicator, which in turn replicates to all other
participating repeaters / VRC gateways. It is recommended to estimate the number of such talkgroup
calls and provide additional uplink and downlink bandwidths at a "replicator site".
• Additional downlink bandwidth at a "replicator site" roughly follows the equation 30.2 kbps x Number
of Talk Groups Having More Than 15 Participating Sites
• Additional uplink bandwidth at a "replicator site" roughly follows the equation 30.2 kbps x Number of
Participating Sites * Number of Talk Groups Having More Than 15 Participating Sites.
A "replicator site" is a site that hosts a Trunking Controller. Selection of a "replicator site" is automatic;
user configuration is not required. A CMSS with a Trunking Controller supports replication / distribution
of packets in its MNIS VRC gateway. For more details on replication, Capacity Max MNIS Voice and
Radio Command (VRC) Gateway on page 37.
If a system has one primary and one or more alternate/redundant Trunking Controllers then the packet
replication / distribution responsibility may automatically be assigned to any of these sites. For
example, during a network outage or power loss to a Trunking Controller that is currently responsible
for packet replication / distribution, then the packet replication / distribution responsibility is
automatically assigned to an Alternate Trunking Controller. All potential packet replication / distribution
sites (Primary and Alternate Trunking Controller sites), need to have the additional uplink and downlink
bandwidth to support packet replication.
• Minimum uplink bandwidth required at a site configured for Centralized Distribution is roughly equal
to the estimated uplink bandwidth at that site with only two (2) sites in the system by using the
charts provided in this section. Use the SDT for a more precise bandwidth calculation.
• At each Trunking Controller (Primary and Alternate) site, an additional downlink bandwidth that is
equal to the sum of the minimum uplink bandwidths of all sites configured for Centralized
Distribution must be provided.
• Similarly, at each Trunking Controller (Primary and Alternate) site, an additional uplink bandwidth
that is equal to the sum of estimated uplink bandwidths of all sites configured for Centralized
Distribution must be provided. Estimated uplink bandwidth is a bandwidth computed for those sites
with Centralized Distribution disabled.
Using the guidance provided for a Centralized Distribution scheme, a few example are provided.
171
MN003523A01-AC
Example 1: An uplink bandwidth limited repeater site having 8 repeaters, no GPS revert repeaters, in
a 9 site system, and using GRE tunneling. Assume that there are 3 Trunking Controllers, one primary
and two alternate, at three different sites.
• Estimated Uplink at repeater site: 1.406 Mbps (read directly from the chart for a 9 site system)
• Minimum Uplink required at repeater site: 0.579 Mbps (read directly from the chart for a 2 site
system)
• Downlink at repeater site: 0.461 Mbps (read directly from the table for 8 repeaters)
• Additional downlink at each Trunking Controller site: 0.579 Mbps (equal to Minimum uplink
bandwidth at repeater site)
• Additional uplink at each Trunking Controller site: 1.406 Mbps (Estimated uplink at repeater site)
Example 2: A repeater site having 8 repeaters with no uplink bandwidth constraint, no GPS revert
repeaters, in a 30 site system, and using GRE tunneling. Let’s assume that there are 3 Trunking
Controllers, one primary and two alternate, at three different sites. Let’s also assume that there are 2
talkgroups, one having 16 participating sites and the other one having 25 participating sites.
• Uplink at repeater site: 1.646 Mbps (Max bandwidth read directly from the chart for a 15 site
system)
• Downlink at repeater site: 0.461 Mbps (read directly from the table for 8 repeaters)
• Additional downlink at each Trunking Controller site: 30.2 kbps x 2 talk groups ~= 0.06Mbps
• Additional uplink at each Trunking Controller site: 30.2 kbps x (16 + 25) ~= 1.24 Mbps
2.10.9
Tunneling Impact on Link Bandwidth Requirements
The following are charts showing uplink bandwidth requirements for a 4 repeater site and a 8 repeater
site, both having no data revert repeaters. The uplink bandwidth requirement is shown as the number
of sites in the system varies. The uplink bandwidth requirement for each of the tunneling modes is also
shown.
NOTICE: The typical ADSL links which is about 1.5 Mbps or better, can easily accommodate
systems having either a large number of sites and a nominal amount of repeaters per site, or a
nominal amount of sites and a large number of repeaters per site.
172
MN003523A01-AC
Figure 37: Uplink Bandwidth Requirements for a Four Repeater Site
Site Uplink Bandwidth Required versus Number of Sites per System

for 4 Trunked Repeaters Site (No data Repeaters)
Site Uplink Bandwidth Required (Mbps)
Number of Sites in the System
Figure 38: Uplink Bandwidth Requirements for an Eight Repeater Site
Site Uplink Bandwidth Required versus Number of Sites per System

for an 8 Trunked Repeaters Site (No data Repeaters)
Site Uplink Bandwidth Required (Mbps)
Number of Sites in the System
173
MN003523A01-AC
2.11
Frequencies Acquired from Frequency Coordinator
This section describes acquiring new frequencies from a frequency coordinator, converting existing
frequency licenses, digital emission designators, and FCC Station Class and Service Class codes.
2.11.1
Acquisition of New Frequencies (Region Specific)
The licensing process varies from region to region. Generally, before the license process begins,
detailed information about the proposed radio system must be provided to the frequency coordinator,
such as:
Frequency/ Frequency Band
Frequency band or specific frequency it operates on.
Subscriber Radio Count
The number of radios that will operate on the system.
Output Power/ERP
The output power of the system amplifier, as well as the effective radiated power (ERP), which is
the system's power at the antenna.
Emission Designators
Includes several pieces of vital information, such as modulation, signal, type of information and size
of the channel. This determines the channel width your system will occupy. See Emission
Designators in this section for more information.
International Coordination
For stations near another country’s border, refer to a frequency coordinating committee for licensing
frequencies adjacent to that country.
Antenna Information
You must also provide the following information about your antenna:
• Structure. the most common codes are:
- B – Building with side mounted antenna
- BANT – Building with antenna on top
- MAST – Self supported structure
- PIPE – Pipe antenna
- POLE – Any type of pole antenna
- TOWER – Free standing guyed structure used for communications purposes
- Height
• Antenna Height. Antenna height from group to tip, in meters.
• Support Structure Height. If antenna is mounted on top of a building, it is the distance from
ground to the top of the building. Check with the building management company for this
information.
Coordinates
Latitude and longitude should be listed in degrees, minutes and seconds.
Site Elevation
The antenna site ground elevation above sea level. This information should always be in meters.
174
MN003523A01-AC
2.11.2
Conversion of Existing Licenses (Region Specific)
The process for converting existing licenses varies between regions and depends on the current
licensing. Contact the local frequency coordinator’s office to inquire how to re-file existing frequency
allocations.
There are also consultants that specialize in frequency coordination and can advise on the filing
process. In the United States, this may include a new emission designator, a new station class code
and/or a new radio service class code.
The following are general guidelines for frequency licenses:
Existing 12.5 kHz Licenses

An update must be filed as follows:
• Existing Analog licenses
- New Emission Designator for all channels (see Digital Emission Designator on page 176)
- Conventional
+ New Radio Service Code for all channels (see Station Class and Radio Service Codes on
page 176)
+ New Station Class for all control channel capable channels (see Station Class and Radio
Service Codes on page 176)
- Decentralized Trunking (that is, LTR or PassPort)
Service Codes on page 176)
- Centralized Trunking (that is, MPT1327 or SmartNet)
+ New Station Class only if adding more control channel capable channels (see Station Class
and Radio Service Codes on page 176)
• Existing MOTORBO licenses
- Conventional
+ New Radio Service Code (see Station Class and Radio Service Codes on page 176)
+ New Station Class (see Station Class and Radio Service Codes on page 176)
- Decentralized Trunking (that is, Capacity Plus or Linked Capacity Plus)
Service Codes on page 176).
- Centralized Trunking (Connect Plus)
+ New Station Class only if adding more control channel capable channels (see Station Class
and Radio Service Codes on page 176).
Existing 25 kHz Licenses

An update must be filed as guided in the “Existing 12.5 kHz Licenses” list with the following caveats.
Typically, the user is allowed to transmit a 12.5 kHz signal bandwidth at the same center frequency as
the original 25 kHz license. It is not a straightforward process to convert an existing 25 kHz license into
a pair of 12.5 kHz channels. Users are not allowed to split their 25 kHz channel into two 12.5 kHz sub-
channels that would operate off center from the original license and adjacent to one another.
175
MN003523A01-AC
2.11.3
Digital Emission Designator
The following emission designators can be used for Capacity Max repeaters and subscribers. The
preferred values should be used unless the old values where already issued for the channel.
The following designators can be used for repeaters:
• Data only: 7K60F7D (preferred) or 7K60FXD (old)
- Data Revert Channels
• Voice only: 7K60F7E (preferred) or 7K60FXE (old)
- Traffic channels on system not supporting any data applications
• Voice and Data: 7K60F7W (preferred) or 7K60FXE (old)
- Control channel capable channels
- Traffic channels on system supporting data applications
If it is likely that the purpose of the channel could change over time, file all channels with a Voice and
Data emission designator.
The following designators can be used for subscribers:
• Data only: 7K60F1D (preferred) or 7K60FXD (old)
- Data Revert Channels
• Voice only: 7K60F1E (preferred) or 7K60FXE (old)
- Traffic channels on system not supporting any data applications
• Voice and Data: 7K60F1W (preferred) or 7K60FXE (old)
- Control channel capable channels
- Traffic channels on system supporting data applications
If it is likely that the purpose of the channel could change over time, file all channels with a Voice and
Data emission designator.
The first four values are defined as the Necessary Bandwidth. This can be derived from the 99%
Energy Rule as defined in Title 47CFR2.989. The next two values are the Modulation Type and the
Signal Type. The final value is the Type of Information being sent. More information can be found with
the region’s frequency coordinating committee.
2.11.4
Station Class and Radio Service Codes
Based on the Federal Communications Commission (FCC) rules in the United States, trunking radio
service can be on shared channels or exclusive channels. To determine the radio service code and
station class code of license needed, consider the following:
• Radio Service Code
- YG = Business/Industrial, Trunking
• Station Class Code
- FB2 = Repeater on shared channel, internal systems
- FB6 = Repeater on shared channel, for profit systems
- FB8 = Repeater on exclusive channel
In the 800/900 MHz bands, the channels are paired (uplink and downlink frequencies) and normally
licensed for exclusive use.
176
MN003523A01-AC
In the UHF band, the channels are paired (uplink and downlink frequencies) and normally licensed for
shared (non-exclusive) use. It requires additional coordination effort to find and license channels for
exclusive use.
In the VHF band, the channels can be paired (uplink and downlink frequencies) or not paired (base/
mobile simplex frequency) – and are normally licensed for shared (non-exclusive) use. It requires
additional coordination effort to find and license shared (non-exclusive) use repeater channels, and
then the additional coordination effort to license repeater channels for exclusive use.
All channels that will be configured as capable of being utilized as a Capacity Max Control Channel
must be exclusive use (FB8), but traffic channels can be either exclusive use (FB8) or shared (non-
exclusive) use (FB2 or FB6). If the traffic channels or data revert channels are expected to have a high
activity level, they should be exclusive use (FB8) as well.
177

Capacity Max System Planner R2.9

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Capacity Max System Planner R2.9

Caricato da

Copyright:

Formati disponibili

System Release 2.

European Union (EU) Waste of Electrical and Electronic Equipment (WEEE)

Version Description Date

- Data over Control Channel

1.4.6 Radio Joining an Active Talkgroup Call................................................................... 31

1.14.1 Call Alert Feature Description................................................................................ 47

1.19.3 North Bound Interface............................................................................................65

1.26.1 Affiliation List Configuration in the Capacity Max Radio........................................ 81

1.33.3 Verification of Users Name.................................................................................... 94

2.4.1 Trunking Type Effects............................................................................................ 131

2.11.2 Conversion of Existing Licenses (Region Specific)..............................................175

Figure 36: Uplink Bandwidth at Site with VRC Gateway(s).................................................................. 169

About the Capacity Max System

What is Covered in This Manual

Helpful Background Information

Related Information Purpose

Related Information Purpose

Table 1: Trunking Methods and the Call Hang Time

cated a new trunked chan-

The probability of dropping a call can be reduced by configuring the repeaters:

Role Candidate Candidate Candidate Candidate Trunked Trunked

• For a talkgroup call, the associated site(s) consist of the following:

Retention of Ongoing Calls

Late Entry to Voice Talkgroup Calls

Priority Monitor Feature

Floor Arbitration of Trunked Channels

Overview of Telephone Architecture and Supported Interface

Overview of Enhanced GPS (EGPS) Revert Channels

Table 2: Number of Updates per Minute per Channel (Slot)

Number of Updates per Minute per Channel (Slot)

Table 3: Number of Updates per Minute per Channel (Slot)

Number of Updates per Minute per Channel (Slot)

Enhanced GPS Revert Channel Data Payload Format Comparison Chart

Location Services via Global Navigation Satellite System

Table 4: GNSS Performance Specifications for GPS

GPS Receiver Portable Mobile

Good Signal Poor Signal Disabled

Location Application Connection to the Radio Network

Overview of Remote Monitor

• The initiating radio ID is registered to the system

Overview of Radio Check Feature

Configuration in the Capacity Max System Server (CMSS)

Call Alert Initiation

Call Alert Feature in Subscriber Access Control (SAC)

Silent with Voice

Emergency Alarm Indication

Emergency Call Indication

Call Preemption at Busy Sites

Emergency Calls Announced on Trunked Channels

Longer Emergency Call Hangtime

Increased Number of Channel Access Attempts

Emergency Alarm Only

Emergency Alarm and Call

Emergency Alarm with Voice to Follow

Table 5: Subscribed Events

Event Name Remarks

Table 6: Configurable Parameters for Presence Notifier

Subscriber Access Control (SAC)

Authentication as an Optional Configuration Setting

Master Key for Simplified Key Management

Physical Serial Number as Enhanced Authentication Mechanism

Table 7: Radio Services

Call Initiation Capability Call Reception Capability

When Stun/Revive authentication option is enabled, on reception of Stun/Revive command, the