advertisement
Professional Digital Two-Way Radio System
m
MOTOTRBO ™
System Planner
Issue 1.0
November 18, 2008
Manual Revisions
Changes which occur after this manual is printed are described in PMRs (Publication Manual
Revisions). These PMRs provide complete replacement pages for all added, changed, and deleted items, including pertinent parts list data, schematics, and component layout diagrams.
Computer Software Copyrights
The Motorola products described in this manual may include copyrighted Motorola computer programs stored in semiconductor memories or other media. Laws in the United States and other countries preserve for Motorola certain exclusive rights for copyrighted computer programs, including, but not limited to, the exclusive right to copy or reproduce in any form the copyrighted computer program. Accordingly, any copyrighted Motorola computer programs contained in the
Motorola products described in this manual may not be copied, reproduced, modified, reverseengineered, or distributed in any manner without the express written permission of Motorola.
Furthermore, the purchase of Motorola 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, except for the normal non-exclusive license to use that arises by operation of law in the sale of a product.
Documentation Copyrights
No duplication or distribution of this document or any portion thereof shall take place without the express written permission of Motorola. No part of this manual may be reproduced, distributed, or transmitted in any form or by any means, electronic or mechanical, for any purpose without the express written permission of Motorola.
Disclaimer
The information in this document is carefully examined, and is believed to be entirely reliable.
However no responsibility is assumed for inaccuracies. Furthermore, Motorola reserves the right to make changes to any products herein to improve readability, function, or design. Motorola does not assume any liability arising out of the applications or use of any product or circuit described herein; nor does it cover any license under its patent rights nor the rights of others.
Trademarks
MOTOROLA, Stylized M logo, and MOTOTRBO are registered in the US Patent & Trademark
Office. All other products or service names are property of their respective owners.
©2008 by Motorola, Inc.
The AMBE+2
TM
voice coding Technology embodied in this product is protected by intellectual property rights including patent rights, copyrights and trade secrets of Digital Voice Systems, Inc.
This voice coding Technology is licensed solely for use within this Communications Equipment.
The user of this Technology is explicitly prohibited from attempting to decompile, reverse engineer, or disassemble the Object Code, or in any other way convert the Object Code into a human-readable form.
U.S. Pat. Nos. #5,870,405, #5,826,222, #5,754,974, #5,701,390, #5,715,365, #5,649,050,
#5,630,011, #5,581,656, #5,517,511, #5,491,772, #5,247,579, #5,226,084 and #5,195,166.
Section 1 Introduction
TM ! ............................................................................... 1
Section 2 System Feature Overview
2.1.1.1 Part One: The Analog to Digital Conversion...................................... 3
2.1.1.2 Part Two: The Vocoder and Forward Error Correction (FEC) ........... 3
2.1.1.4 Part Four: TDMA Transmission ......................................................... 4
2.1.2 Spectrum Efficiency via Two-Slot TDMA .................................................... 5
2.1.2.1 Frequencies, Channels, and Requirements for Spectrum Efficiency 5
2.1.2.2 Delivering Increased Capacity in Existing 12.5kHz Channels ........... 5
2.1.2.3 Two-Slot TDMA Reduces Infrastructure Equipment.......................... 6
2.1.2.4 Two-Slot TDMA Enables System Flexibility....................................... 8
2.1.2.5 Two-Slot TDMA System Planning Considerations ............................ 9
2.1.3 Digital Audio Quality and Coverage Performance....................................... 9
2.1.3.2 Predicting Digital Audio Coverage ................................................... 11
2.1.3.3 User Expectations for Digital Audio Performance............................ 12
2.2 Basic System Topologies for Digital and Analog Operations ............................. 14
2.2.1 Repeater and Direct Mode Configurations................................................ 14
2.2.2 MOTOTRBO Supports Analog and Digital Operation ............................... 16
2.2.3 MOTOTRBO Channel Access .................................................................. 16
2.2.3.1 Impolite Operation (Admit Criteria of “Always”) ............................... 17
2.2.3.2 Polite to All Operation (Admit Criteria of “Channel Free”)................ 18
2.2.3.3 Polite to Own Digital System Operation
(Admit Criteria of “Color Code Free”) ................................................... 18
2.2.3.4 Polite to Own Analog System Operation
(Admit Criteria of “Correct PL”) ............................................................ 18
2.2.3.5 Polite or Impolite While Participating in a Call (In Call Criteria) ....... 18
2.2.3.6 Repeater Wake-up Provisioning ...................................................... 19
i
ii
2.3.2.2 Radio Disable (Selective Radio Inhibit) ........................................... 22
2.3.3.1 Emergency Alarm Only.................................................................... 26
2.3.3.2 Emergency Alarm and Call .............................................................. 26
2.3.3.3 Emergency Alarm with Voice to Follow ........................................... 27
2.4.2.1 Built-In Text Messaging Service ...................................................... 30
2.4.2.2 Services Provided to a Third Party Text Message Application ........ 31
2.4.3.1 Performance Specifications ............................................................. 33
2.4.3.2 Services Provided to a Radio User.................................................. 34
2.4.3.3 Services Provided to a Location Application.................................... 34
2.4.4.1 Physical Connection Information ..................................................... 38
2.5.3.1 Scanning and Preamble .................................................................. 42
2.5.3.2 Channel Scan and Last Landed Channel ........................................ 44
2.5.3.3 Scan Members with Similar Receive Parameters............................ 45
2.6.3.3 Configuring the Roaming RSSI Threshold....................................... 53
2.6.3.4 Setting Beacon Duration and Beacon Interval................................. 58
2.6.3.5 Emergency Revert, GPS Revert, and Roaming Interactions........... 60
2.6.3.6 Performance while Roaming............................................................ 61
2.7.2 Strength of the Protection Mechanism ...................................................... 63
2.7.9 Multiple Keys in a Basic Privacy System .................................................. 68
2.7.11 Protecting One Group’s Message from Another ..................................... 69
2.7.12 Updating from Basic Privacy to Enhanced Privacy ................................. 70
2.8.1 Connecting Remotely via the Network ...................................................... 72
2.8.3.1 RDAC Local Settings Rear Accessory Port CPS
Programmable Pins.............................................................................. 74
2.10.2 MDC Analog Signaling Features............................................................. 79
2.10.4.1 Analog Repeater Interface Settings............................................... 80
2.10.4.2 Configuration Summary Table ....................................................... 83
2.10.4.3 Configuration Considerations ........................................................ 83
2.11.1 MOTOTRBO, the Dealer, and the Accredited Third-Party Developer..... 88
2.11.2 MOTOTRBO Applications Interfaces ...................................................... 88
2.11.3 MOTOTRBO Documents Available via the Third Party Application Partner
iii
Section 3 System Components and Topologies
3.1.1.3 MC1000, MC2000, MC2500 Console.............................................. 95
3.1.2.1 MOTOTRBO Portable...................................................................... 96
3.1.2.2 MOTOTRBO Mobile ...................................................................... 101
3.2.1.1 Digital MOTOTRBO Radios in Direct Mode................................... 107
3.2.1.2 Interoperability between Analog MOTOTRBO Radios and Analog
Radios in Direct Mode........................................................................ 116
3.2.1.3 Interoperability between Digital MOTOTRBO Radios, Mixed Mode
MOTOTRBO Radios, and Analog Radios in Direct Mode.................. 117
3.2.2.1 Digital MOTOTRBO Radios in Repeater Mode ............................. 119
3.2.2.2 Analog MOTOTRBO Radios in Repeater Mode ............................ 130
3.2.3.1 Topologies of IP Site Connect System .......................................... 132
Section 4 System Design Considerations
4.2.1 Pre-Deployment System Integration ....................................................... 143
4.2.2 Analog to Digital Preparation and Migration............................................ 143
4.3.1 Acquiring New Frequencies (Region Specific)........................................ 144
4.3.2 Converting Existing 12.5/25kHz Licenses............................................... 145
4.3.3 Repeater Continuous Wave Identification (CWID).................................. 146
4.4.4 Loading Optimization and Configuration Considerations ........................ 149
4.4.4.1 Distribution of High Usage Users................................................... 149
iv
4.4.4.2 Minimize Location Periodic Update Rate....................................... 150
4.4.4.3 Data Application Retry Attempts and Intervals .............................. 151
4.4.4.4 Optimize Data Application Outbound Message Rate .................... 152
4.4.4.5 GPS Revert and Loading............................................................... 152
4.5.3 Additional Considerations for Color Codes ............................................. 157
4.6 Multiple Digital Repeaters in IP Site Connect Mode......................................... 158
4.6.2 Frequencies and Color Code Considerations ......................................... 158
4.6.3 Considerations for the Back-End Network .............................................. 159
4.6.3.1 Automatic Reconfiguration............................................................. 160
4.6.3.2 Characteristics of Back-End Network ............................................ 161
4.6.4 Flow of Voice/Data/Control Messages .................................................... 168
4.6.6 General Considerations When Setting Up the Network Connection for an IP
4.6.7 Considerations for Shared Use of a Channel.......................................... 171
4.7.1 Computer and IP Network Configurations............................................... 172
4.7.1.1 Radio to Mobile Client Network Connectivity................................. 172
4.7.1.2 Radio to Air Interface Network Connectivity .................................. 174
4.7.1.3 Application Server Control Station Network Connectivity .............. 176
4.7.1.4 Control Station Considerations ...................................................... 178
4.7.1.5 Multi-Channel Device Driver (MCDD) and Required Static Routes 179
4.7.1.6 Application Server and Dispatcher Network Connectivity.............. 179
4.7.1.7 MOTOTRBO Subject Line Usage.................................................. 180
4.7.1.8 MOTOTRBO Example System IP Plan ......................................... 180
4.7.1.9 Application Server Network Connection Considerations ............... 182
4.7.2 Mobile Terminal and Application Server
Power Management Considerations................................................................ 182
4.8.1 Identifying a Functional Fleetmap Design Team..................................... 183
4.8.3 Organizing Radio Users into Groups ...................................................... 184
4.8.3.1 Configuration of Groups................................................................. 185
4.8.4.2 Assigning Radio Aliases ................................................................ 187
v
4.8.4.4 Assigning Group Aliases................................................................ 188
4.8.5 Determining Which Channel Operates in Repeater Mode or
4.8.6 Determining Feature Assignments.......................................................... 189
4.8.6.1 Determining Supervisor Radios ..................................................... 189
4.8.7 Emergency Handling Configuration ........................................................ 191
4.8.7.1 Emergency Handling User Roles................................................... 191
4.8.7.2 Emergency Handling Strategies .................................................... 192
4.8.7.3 Acknowledging Supervisors in Emergency.................................... 194
4.8.7.4 Extended Emergency Call Hang time............................................ 194
4.8.7.5 Emergency Revert and GPS Revert Considerations..................... 194
4.8.9 Zones and Channel Knob Programming................................................. 199
4.9 Base Station Identifications (BSI) Setting Considerations................................ 200
4.11.1 Direct Mode Fallback (Talkaround) ....................................................... 202
4.11.2 Uninterrupted Power Supplies (Battery Backup)................................... 202
Section 5 Sales and Service Support Tools
5.1 Purpose ............................................................................................................ 209
5.3.1 Recommended Test Equipment.............................................................. 209
5.4.1 MOTOTRBO Documentation .................................................................. 211
vi
Introduction
SECTION 1 INTRODUCTION
1.1 Welcome to MOTOTRBO
TM
!
Improving workforce productivity and operational effectiveness requires superior communications quality, reliability, and functionality. MOTOTRBO is the first digital two-way radio system from
Motorola specifically designed to meet the requirements of professional organizations that need a customizable, business critical, private communication solution using licensed spectrum.
MOTOTRBO combines the best in two-way radio functionality with digital technology to deliver increased capacity and spectral efficiency, integrated data applications and enhanced voice communications.
MOTOTRBO is an integrated voice and data system solution comprising of mobile and portable radios, audio and energy accessories, repeaters, and a third party application partner program.
1
Figure 1.1 MOTOTRBO System
This system planner will enable the reader to understand the features and capabilities of the
MOTOTRBO system, and will provide guidance on how to deploy and configure the system and its components to take advantage of its advanced capabilities.
This system planner is divided into 5 sections, with the first being this introduction. Section 2 provides an overview of system level features. Section 3 describes the system components in more detail. Section 4 provides guidance on system design considerations including configuration of components. Section 5 provides product sales and support information.
This system planner is complementary to additional training and documentation including:
• Radio Customer Programming Software (CPS) and related training
• System workshop/system service training
• Product specification sheets
November, 2008
2 Introduction
1.2 Software Version
All the features described in the System Planner are supported by the radio’s software version
R04.00.00 or later.
November, 2008
System Feature Overview
SECTION 2 SYSTEM FEATURE OVERVIEW
2.1 MOTOTRBO Digital Radio Technology
This section provides a brief overview of MOTOTRBO digital radio technology. It addresses two of the primary benefits delivered by this technology: spectral efficiency and improved audio performance.
2.1.1 Digital Radio Technology Overview
The digital radio technologies employed by MOTOTRBO can be summarized as follows:
3 or
1 2 3 4
Figure 2-1 MOTOTRBO Digital Radio Technology
Figure 2-1 “MOTOTRBO Digital Radio Technology” is broken down into four parts which are
described in the following subsections.
2.1.1.1 Part One: The Analog to Digital Conversion
When a radio user presses the Push-To-Talk (PTT) button and begins speaking, his voice is received by the radio microphone and converted from an acoustic waveform to an analog electrical waveform. This voice waveform is then sampled by an analog to digital converter. In typical radio applications, a 16-bit sample is taken every 8kHz, this produces a 128,000bps (bits per second) digital bitstream, which contains far too much information to send over a 12.5kHz or
25kHz radio channel. Therefore some form of compression is required.
2.1.1.2 Part Two: The Vocoder and Forward Error Correction (FEC)
Vocoding (Voice encoding) compresses speech by breaking it into its most important parts and encoding them with a small number of bits, while greatly reducing background noise. Vocoding compresses the voice bitstream to fit the narrow (for MOTOTRBO) 6.25kHz equivalent radio channel. The MOTOTRBO vocoder is AMBE+2 TM which was developed by Digital Voice System,
Inc. (DVSI), a leader in the vocoding industry. This particular vocoder works by dividing speech into short segments, typically 20 to 30 milliseconds in length. Each segment of speech is analyzed, and the important parameters such as pitch, level, and frequency response are extracted. These parameters are then encoded using a small number of digital bits. The AMBE+2 TM vocoder is the
November, 2008
4 System Feature Overview first to demonstrate very low bit rates while producing toll-quality speech such as traditionally associated with wireline telephone systems.
Together with the vocoding process, Forward Error Correction (FEC) is also applied. FEC is a mathematical checksum technique that enables the receiver to both validate the integrity of a received message and determine which, if any, bits have been corrupted. FEC enables the receiver to correct bit errors that may have occurred due to radio frequency (RF) channel impairment. This effectively rejects noise that can distort an analog signal and by comparison enables more consistent audio performance throughout the coverage area. At this stage, the vocoder has already compressed the 128,000bps input signal to 3,600bps.
2.1.1.3 Part Three: Framing
In framing, the vocoded speech is formatted for transmission. This includes organizing the voice and any embedded signaling information (such as color code, group ID, PTT ID, call type, etc.) into packets. These packets form a header and payload type of structure – the header contains the call control and ID information, and the payload contains the vocoded speech. This same structure can also relay Internet Protocol (IP) data packets – the IP packets are simply an alternative form of payload to the MOTOTRBO radio. The header information is repeated periodically throughout the transmission, thereby improving the reliability of the signaling information as well as enabling a receiving radio to join a call that may already be in progress – we refer to this condition as “late entry”.
2.1.1.4 Part Four: TDMA Transmission
Finally, the signal is encoded for a Frequency Modulation (FM) transmission. The bits contained in the digital packets are encoded as symbols representing the amplitude and phase of the modulated carrier frequency, amplified, and then transmitted.
TDMA (Time Division Multiple Access) organizes a channel into 2 time slots: a given radio’s transmitter is active only for short bursts, which provides longer battery life. By transmitting only on their alternating time slots, two calls can share the same channel at the same time without interfering with one another, thereby doubling spectrum efficiency. Using TDMA, a radio transmits only during its time slot (i.e. it transmits a burst of information, then waits, then transmits the next burst of information).
2.1.1.5 Standards Compliance
The digital protocols employed in MOTOTRBO (from vocoding and forward error correction to framing, transmission encoding, and transmission via two-slot TDMA) are fully specified by the
ETSI 1 DMR 2 Tier 2 3 Standard, which is an internationally recognized standard with agreements among its supporting members. Although formal interoperability testing and verification processes for this standard have yet to fully mature, Motorola anticipates that MOTOTRBO radio systems will be interoperable with other solutions that comply to the ETSI DMR Tier 2 standard.
1.
European Telecommunications Standards Institute
2.
Digital Mobile Radio
3.
Tier 2 indicates full power conventional operation in licensed channels for professional and commercial users.
November, 2008
System Feature Overview
2.1.2 Spectrum Efficiency via Two-Slot TDMA
2.1.2.1 Frequencies, Channels, and Requirements for Spectrum Efficiency
A radio communications channel is defined by its carrier frequency, and its bandwidth. The spectrum of available carrier frequencies is divided into major bands (such as VHF and UHF), and the majority of licensed channels in use today have widths of either 25kHz or 12.5kHz. As the airwaves have become increasingly crowded, new standards and technologies that allow more radio users to share the available spectrum in any given area are needed. The demand for greater spectral efficiency is being driven, in part, by regulatory agencies. In the U.S., for example, the
Federal Communications Commission (FCC) requires manufacturers to offer only devices that operate within 12.5kHz VHF and UHF channels by 2011. By the year 2013, all VHF and UHF users are required to operate in 12.5kHz channels.
The next logical step is to further improve the effective capacity of 12.5kHz channels. While there is no current mandate requiring a move to 6.25kHz, such discussions are on-going at the FCC and other agencies. It’s only a matter of time before the ability to carry two voice paths in a single
12.5kHz channel, also known as 6.25kHz equivalent efficiency, becomes a requirement in VHF and UHF bands. Presently, FCC rules are in place to mandate manufacturers to build radios capable of the 6.25kHz efficiency for VHF and UHF bands, but the enforcement of these rules are put on hold. In the meantime, MOTOTRBO offers a way to divide a 12.5kHz channel into two independent time slots, thus achieving 6.25kHz-equivalent efficiency today.
2.1.2.2 Delivering Increased Capacity in Existing 12.5kHz Channels
MOTOTRBO uses a two-slot TDMA architecture. This architecture divides the channel into two alternating time slots, thereby creating two logical channels on one physical 12.5kHz channel.
Each voice call utilizes only one of these logical channels, and each user accesses a time slot as if it is an independent channel. A transmitting radio transmits information only during its selected slot, and will be idle during the alternate slot. The receiving radio observes the transmissions in either time slot, and relies on the signaling information included in each time slot to determine which call it was meant to receive.
5
November, 2008
6 System Feature Overview
By comparison, analog radios operate on the concept of Frequency Division Multiple Access
(FDMA). In FDMA, each transmitting radio transmits continuously on a designated channel, and the receiving radio receives the relevant transmission by tuning to the desired carrier frequency.
Regulatory emissions mask
Time
Slot 2
Slot 1
Slot 2
Slot 1
Slot 2
Slot 1
Frequency
Frequency
12.5KHz channel
12.5KHz channel
12.5kHz Analog
- 1 voice for each 12.5kHz channel
- A single repeater for each channel
12.5kHz TDMA
- Divides existing channel into two timeslots
- Delivers twice the capacity through repeater
- Performance is same or better than 12.5kHz FDMA
- Single repeater does work of two repeaters
- Reduces need for combining equipment
- Enables 40% increase in radio battery life
Figure 2-2 Comparison between Today’s Analog and MOTOTRBO
TDMA thereby offers a straightforward method for achieving 6.25kHz equivalency in 12.5kHz
repeater channels – a major benefit for users of increasingly crowded licensed bands. Instead of dividing channels into smaller slices of decreased bandwidth – which is what would be required to increase spectrum efficiency with FDMA methods, TDMA uses the full 12.5kHz channel bandwidth, but increases efficiency by dividing it into two alternating time slots. Additionally, this method preserves the well-known radio frequency (RF) performance characteristics of the
12.5kHz signal. From the perspective of RF physics – that is, actual transmitted power and radiated emissions – the 12.5kHz signal of two-slot TDMA occupies the channel, propagates, and performs essentially in the same way as today’s 12.5kHz analog signals. With the added advantages of digital technology, TDMA-based radios can work within a single repeater channel to provide roughly twice the traffic capacity, while offering RF coverage performance equivalent to, or better than, today’s analog radio.
2.1.2.3 Two-Slot TDMA Reduces Infrastructure Equipment
As we have seen, two-slot TDMA essentially doubles repeater capacity. This means that one
MOTOTRBO repeater does the work of two analog repeaters (a MOTOTRBO repeater supports two calls simultaneously). This saves costs of repeater hardware and maintenance, and also saves on the cost and complexity of RF combining equipment necessary in multi-channel configurations. Just as importantly, the two-slot TDMA signal fits cleanly into a customer’s existing, licensed channels; there is no need to obtain new licenses for the increase in repeater capacity,
November, 2008
System Feature Overview 7 and compared to alternative technologies that may operate on different bandwidths, there is no comparative increase in the risk of interference with or from adjacent channels.
Analog 2-Channel System
12.5kHz Analog
Frequency Pair 1
Repeater 1
Tx1
Rx1
Tx2
Rx2
Combining
Equipment
Frequency Pair 2
Groups
Repeater 2
MOTOTRBO 2-Channel System
12.5kHz TDMA
Repeater
Tx
Rx
Duplexer
Frequency Pair
Figure 2-3 MOTOTRBO Requires Less Combining Equipment
Groups
November, 2008
8 System Feature Overview
2.1.2.4 Two-Slot TDMA Enables System Flexibility
The two time slots or logical channels enabled by two-slot TDMA can potentially be used for a variety of purposes. Many organizations deploying MOTOTRBO systems can use these slots in the following manner:
• Use both the slots as voice channels. This doubles the voice capacity per licensed repeater channel, thereby
• increasing the number of users the system can accommodate, and
• increasing the amount of air time the users can consume.
• Use both slots as data channels. This allows the organizations to fully deploy data transactions
• Use one slot as a voice channel, and the other as a data channel. This is a flexible solution, that allows customers to equip their voice users with mobile data, messaging, or location tracking capabilities.
In any of these scenarios, additional benefits are realized within the existing licensed repeater channel(s).
Voice Call 1 (or Data)
Timeslot 1 Timeslot 2 Timeslot 1 Timeslot 2 Timeslot 1 Timeslot 2
Voice Call 2 (or Data)
Figure 2-4 Example of Two-Slot TDMA
November, 2008
System Feature Overview 9
NOTE: When used in direct mode without a repeater, two-slot TDMA systems on a 12.5kHz
channel do not deliver 6.25kHz equivalent efficiency. This is because the repeater is necessary to synchronize the time slots to enable independent parties to share them.
Thus, on a direct or talkaround channel, when one radio begins transmitting, the whole
12.5kHz channel is effectively busy, even though the transmitting radio is using only one time slot. The alternate time slot is unavailable for another, independent voice call.
However, the alternate time slot can potentially be utilized as a signaling path. The ETSI
DMR Tier 2 standard refers to this capability as Reverse Channel signaling, and it is envisioned to be used to deliver important future benefits to professional users, such as priority call control, remote-control of the transmitting radio, and emergency call preemption. This future capacity for reverse channel signaling is a unique capability of TDMA technology and, if supported by your system, may be deployed in both repeater and direct/ talkaround configurations. At this time, the MOTOTRBO system does NOT support
Reverse Channel signaling.
2.1.2.5 Two-Slot TDMA System Planning Considerations
System Planning considerations associated with the increased capacity and the flexibility of the
MOTOTRBO two-slot TDMA architecture include:
• Capacity planning:
• How many voice and data users do you have?
• What usage profiles are anticipated?
• How many channels and repeaters are needed?
These questions are addressed in more detail in “System Design Considerations” on page 143.
• Fleetmapping:
• How to map users, voice services and data services such as messaging or location tracking to channels.
Voice and data service capabilities are described in more detail in this module and in “System
Components and Topologies” on page 93. Fleetmapping considerations are addressed in
more detail in “System Design Considerations” on page 143, in the MOTOTRBO Systems
Training, and within the MOTOTRBO radio CPS.
• Migration Planning:
• How to migrate existing channels to digital channels?
• What updates to licensing requirements may be needed?
2.1.3 Digital Audio Quality and Coverage Performance
This section describes how digital audio drives coverage performance. It also sets expectations for how digital audio behaves and sounds from the end-user’s perspective.
November, 2008
10 System Feature Overview
2.1.3.1 Digital Audio Coverage
The main difference between analog and digital coverage is how the audio quality degrades throughout the coverage region. Analog audio degrades linearly throughout the region of coverage, while digital audio quality performs more consistently in the same region of coverage. A primary reason for the different degradation characteristics is the use of forward error correction coding used in digital transmissions, which can accurately deliver both audio and data content with virtually no loss over a far greater area.
It is this error protection that allows a MOTOTRBO system to provide consistent audio quality throughout its coverage area. A comparable analog system can never offer such consistency. In the MOTOTRBO system, the audio quality remains at a high level, because the error protection minimizes the noise effect.
The figure below graphically illustrates the relationship of delivered system audio quality, while comparing good to poor audio quality with strong to weak signal strength. Do note that
• In very strong signal areas the analog signal, because there is no processing, may sound slightly better than the digital audio signal.
• Digital signals increase the effective coverage area above the minimally acceptable audio quality level.
• Digital signals improve the quality and consistency of the audio throughout the effective coverage area.
• Digital signals do not necessarily increase the total distance that an RF signal propagates.
Figure 2-5 Comparison of Audio Quality versus Signal Strength for Analog and Digital
November, 2008
System Feature Overview 11
2.1.3.2 Predicting Digital Audio Coverage
Predicting coverage for a radio site can be complicated. There are many factors that affect RF performance prediction, and generally, 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.
Coverage prediction techniques for analog and digital systems generally follow the same basic procedures, and require similar sets of input factors. Therefore, if the site’s analog coverage footprint is already known, it is easier to plan the site’s digital coverage footprint. This approach allows the system designer to use their existing analog site coverage prediction techniques, whether simple or complex, and then translate the results of the analog coverage prediction to predict digital coverage.
Delivered Audio Quality (DAQ) is a method to quantify audio quality. It is a measure of the intelligibility and quality of voice transported through a communications system, as defined in TIA
TSB-88. DAQ reports audio quality on a 5 point scale, with a DAQ rating of 3 considered as the minimal acceptable level of audio quality for public safety applications. The definition of DAQ 3 is
“Speech understandable with slight effort and occasional repetition required due to Noise/
Distortion.”.
When comparing an analog site and a MOTOTRBO site, the relative regions of coverage offering comparable audio quality are illustrated in the figure below.
Analog Digital
Improving Audio Quality
Figure 2-6 Differences in Analog Coverage
For a DAQ 3 audio quality, MOTOTRBO provides a greater usable range than analog, when all other factors are considered equal (e.g. transmit power level, antenna height, receiver noise figures, IF filter bandwidths, no audio processing – such as Hear Clear – on the analog radios, terrain, antenna combining equipment, etc.).
November, 2008
12 System Feature Overview
For an advanced, more comprehensive understanding of RF coverage prediction for the
MOTOTRBO site, the reader is encouraged to obtain the TIA Telecommunications Service Bulletin
TSB-88 – “Wireless Communications Systems-Performance in Noise and Interference-Limited
Situations, Recommended Methods for Technology-Independent Modeling, Simulation, and
Verification.”
A copy of TSB-88 can be obtained from http://www.tiaonline.org
2.1.3.3 User Expectations for Digital Audio Performance
There are a number of differences between how digital audio behaves compared to analog audio from the end user (listener’s) perspective. Motorola has found that setting proper end user expectations in this regard is an important aspect of system planning.
What End-Users will Experience with Digital Audio
• Consistent performance throughout coverage area with no gradual fade at the
fringes: While analog signals slowly degrade as the receiver moves away from the transmitter, digital signals perform more consistently throughout the coverage area.
However, digital signals, more abruptly, shift from “good” to “no signal”, when crossing the fringe of the coverage area. This means, users cannot rely on degrading audio quality to warn them that they are approaching the fringe of coverage. On the other hand, just prior to the fringe of the coverage area, digital audio is still crisp and clean, whereas analog audio has excessive noise and static.
• Digital Sounds Different: The vocoding process is designed to deliver optimum audio quality with a very small number of bits. Some listeners find the resulting tonal qualities of digital speech somewhat different from what they have experienced with analog speech.
Because the vocoding process is highly specialized for reproducing human speech, other sounds like music and tones are not reproduced accurately. Additionally, digital audio can introduce end-to-end audio delays. When overwhelming errors or dropouts are encountered, digital radios can generate some unique-sounding audio “artifacts”.
• Background Noise Reduction: The advanced vocoding capabilities in MOTOTRBO also include background noise reduction. Regardless of what is happening in the environment of the transmitting radio, only voice is reconstructed at the receiving radio – background noise, like machine noise, wind noise, and traffic noise, is not reconstructed, and thus, not heard.
This is a key advantage of the MOTOTRBO digital voice solution over typical analog solutions, because noisy environments like factories, stores, work sites, and windy locations do NOT significantly degrade communication intelligibility.
What End-Users will NOT Experience with Digital Audio:
• Digital radio is not “CD Quality.” MOTOTRBO is the first radio in the industry to use the
AMBE+2
TM
low bit rate vocoder to deliver communications grade voice quality. End users should not be misled into thinking that “communications grade” digital audio quality in radio systems is analogous to the high fidelity audio quality of CD’s and DVD’s.
• Digital cannot solve historic problems. System issues with coverage and interference are not necessarily eliminated by switching to digital. Adjacent or co-channel interference may sound different to a digital user, but digital technology does not solve interference issues.
For example, analog interference will not be heard as voice to a digital radio and vice versa, but disruption of system performance can still occur.
November, 2008
System Feature Overview 13
2.1.3.4 Audio Balancing
Transmitting voice over a digital air interface requires a voice coder, or vocoder for short. The vocoder used by MOTOTRBO is the Digital Voice Systems Inc. (DVSI) AMBE+2 TM . This vocoder delivers excellent voice quality with robustness to both background noise and RF channel bit errors in a 6.25 kHz equivalent channel bandwidth. In order to produce optimal voice quality, the input level into the vocoder must fall within a specific amplitude range.
The diverse nature of users with respect to mouth-to-microphone distance as well as voice level and directivity can make this a bit problematic. In an effort to produce optimal voice quality over these diverse input conditions, MOTOTRBO digital always employs Automatic Gain Control (AGC) in the audio transmit path. The primary function of the transmit AGC is to produce the best voice quality possible under real life conditions. Since voice is still the main application of a two-way radio, this is a primary goal.
A secondary result of the AGC is to produce flat received speech loudness level over a range of input levels at the microphone. The usage of IMPRES Accessories extends this input range so
optimal voice quality occurs over an even greater input range. Figure 2-7 “Transmit Audio
Sensitivity” illustrates this extended range flat response in the curve titled MOTOTRBO with
IMPRES RSM (Digital). This same response curve can also be produced in analog mode by using
a IMPRES Accessory and enabling Analog Mic AGC in the CPS General Settings. Figure 2-7
illustrates this type of response in the curve titled MOTOTRBO with IMPRES RSM (AGC on,
Analog). An advantage of this type of response is that soft talkers and users that turn away from the microphone while speaking will still come through loud and clear.
100
95
90
85
80
75
80
Professional Series
MOTOTRBO with IMPRES RSM (AGC off, Analog)
MOTOTRBO with IMPRES RSM (AGC on, Analog)
MOTOTRBO with IMPRES RSM (Digital)
105 85 90 95
Transmitter Input [dB SPL]
100
Figure 2-7 Transmit Audio Sensitivity
110
November, 2008
14 System Feature Overview
The flat audio response of digital is different from the traditional analog audio response. The traditional response is a linear response and the louder one speaks, then the louder the received
and MOTOTRBO with IMPRES RSM (AGC off, Analog). When Analog Mic AGC is disabled, then the Analog Mic Gain (dB) is adjustable in the CPS General Settings. Therefore, MOTOTRBO in analog mode is able to deliver the traditional analog response and is adjustable to fit into existing systems.
Examination of Figure 2-7 indicates that digital and traditional analog responses are similar at an
input Sound Pressure Level (SPL) of 98 dB. Below this level, analog is quieter than digital. This is important to note as a system requiring MOTOTRBO to function as a digital radio and also as an analog radio during migration, may experience received audio level differences that are mode dependant. This could occur when scanning both digital and analog channels and the analog talker is located in a quiet environment such as an office. In quiet environments many users tend to speak softly and therefore the input will fall below the equivalent response level of 98 dB SPL.
Therefore, during the migration period, the analog response may be quieter than the digital response.
2.2 Basic System Topologies for Digital and Analog
Operations
MOTOTRBO is a conventional radio system. In its most basic form, a MOTOTRBO system is comprised of radios that communicate to each other directly in direct mode, through a repeater in repeater mode, or through a set of repeaters in IP Site Connect Mode. The MOTOTRBO system can be configured to operate in analog mode, digital mode, or in both modes.
2.2.1 Repeater and Direct Mode Configurations
In repeater-based radio communications systems, a voice path requires a pair of channels: one for transmission, the other for reception.
• When operating in analog repeater mode, MOTOTRBO operates similar to existing analog repeaters by supporting one voice path (transmit and receive) on one pair of physical channels, and can be configured to operate in 25kHz channel bandwidth systems and/or
12.5kHz channel bandwidth systems.
• When operating in digital repeater mode, MOTOTRBO uses a pair of physical channels configured for 12.5kHz channel bandwidth. Through the use of Time Division Multiple
Access (TDMA) technology and the synchronization provided by the repeater, MOTOTRBO splits each 12.5kHz channel (one transmit and one receive) into two independent time slots or logical channels within the 12.5kHz physical channel bandwidth. This allows the user to assign voice or data traffic to either of the time slots independently. To the end user, this means they now have two voice or data channels that can be managed independently, instead of one. These two logical channels (two time slots) can transmit and receive independently of each other.
• When operating in IP Site Connect mode, MOTOTRBO combines the logical channels of multiple MOTOTRBO systems operating in digital repeater mode. In this mode, repeaters across dispersed locations exchange voice and data packets over an IPv4-based back-end network. There are three main functions of this mode.
1. To increase the RF coverage area of a MOTOTRBO system.
November, 2008
System Feature Overview 15
2. To provide voice and data communication between two or more MOTOTRBO single site systems located at geographically separate locations.
3. To provide voice and data communication between two or more MOTOTRBO single site systems operating in different frequency bands (e.g. UHF and VHF).
The back-end network of an IP Site Connect system is designed to work seamlessly with internet connectivity provided by an Internet Service Provider (ISP). The system only requires that one of the repeaters have a static IPv4 address, while the others may be dynamic. Also, the system avoids the need for reconfiguration of a customer’s network such as reprogramming of firewalls.
When a new call starts at one of the logical channel of a repeater, the repeater sends the call to all the repeaters and all these repeaters repeat the call on their corresponding logical channel. This allows a radio in the coverage area of any repeater to participate in the call. Thus, the coverage area of an IP Site Connect system is the sum of the coverage areas of all the repeaters. However, note that an IP Site Connect configuration does not increase the capacity (i.e. number of calls per hour) of the system. The capacity of one Wide Area Channel of an IP Site Connect system is approximately the same as that of a single repeater working in digital repeater mode.
In an IP Site Connect configuration, MOTOTRBO radios support all the features that they already support in digital repeater mode. Additionally, the radios are capable of automatically roaming from one site to another.
The IP Site Connect configuration of MOTOTRBO does not require any new hardware besides back-end network devices such as routers. If a customer has multiple MOTOTRBO systems working in digital repeater mode at dispersed sites and wants to convert them into an IP Site
Connect system then the repeaters and the radios should be updated with new software and the repeaters need to be connected to an IPv4 based back-end network. It is possible to configure a repeater such that
• both logical channels work in IP Site Connect mode (i.e. over wide area).
• both logical channels work in digital repeater mode (i.e. single site over local area).
• one of its logical channels works in IP Site Connect mode (i.e. over wide area) and the other logical channel works in digital repeater mode (i.e. single site over local area).
MOTOTRBO has three security features in the IP Site Connect configuration.
• Provides the confidentiality of voice and data payloads by extending the privacy feature, whether Basic or Enhanced, to cover the communication over the back-end network.
• Ensures that all the messages between repeaters are authentic.
• Supports Secure VPN (Virtual Private Network) based communication between the repeaters for customers needing higher level of security (protection against replay attack).
The IP Site Connect configuration of MOTOTRBO provides a mechanism and a tool to remotely manage repeaters. The tool (called RDAC) receives alarms from all the repeaters, helps in diagnosis of repeaters, and provides some controls over the repeaters
In direct mode, receive and transmit functions are both carried out on the same physical channel
(i.e. transmit and receive frequencies are the same).
• When operating in analog direct mode, MOTOTRBO supports one voice path (transmit and receive) on one physical channel, and can be configured to operate in 25kHz channel bandwidth systems and/or 12.5kHz channel bandwidth systems.
November, 2008
16 System Feature Overview
• When operating in digital direct mode, MOTOTRBO uses one physical channel configured for 12.5kHz channel bandwidth. On one direct 12.5kHz physical channel bandwidth, a
MOTOTRBO digital system can support only one voice (or data) path at a time. Without a repeater in place to coordinate the time slot sequence among radios, only one radio can transmit at a time in order to guarantee transmissions do not overlap.
Greater detail on system services available in direct-mode and repeater-based system topologies
is described in “System Components and Topologies” on page 93.
2.2.2 MOTOTRBO Supports Analog and Digital Operation
The MOTOTRBO system can be configured to operate in analog mode, digital mode, or in both modes. Though a system can consist of multiple repeaters, a single MOTOTRBO repeater can only operate as either analog or digital. MOTOTRBO repeaters cannot dynamically switch between analog and digital modes.
MOTOTRBO portable and mobile radios can communicate in analog and digital. The mobile or portable radio user selects the mode of operation (analog or digital), and physical and logical channel using his channel selector knob (each channel selection position is configured for a particular call type on either a digital channel that specifies both frequency and time slot, or an analog channel that specifies both frequency and 25kHz or 12.5kHz bandwidth). Radio channels are either analog or digital. This is configured by the CPS. The radio can scan between analog and digital channels.
Greater detail on channel planning and configuration is provided in “System Design
2.2.3 MOTOTRBO Channel Access
Channel access dictates what conditions a radio is allowed to initiate a transmission on a channel.
The channel access rules of MOTOTRBO are governed by the mobile and portable radios. It is the radio’s responsibility to assess the state of the system, and utilize its channel access rules to decide whether to grant the call to the user.
In repeater systems, it is the repeater’s responsibility to:
• Identify if a channel is busy, or
• Identify if a channel is idle, or
• Inform for which radio the channel is reserved.
The repeater does not block or deny any channel access from radios on its system, but will not repeat transmissions from another system.
There are two main types of channel access in a MOTOTRBO system: Polite and Impolite access.
In the configuration software, channel access is referred to as the Admit Criteria. MOTOTRBO supports the following Admit Criteria:
• Always: This criteria is often referred to as "Impolite” channel access, and can be applied to analog and digital channels.
• Channel Free: This criteria is often referred to as “Polite to All”, and can be applied to analog and digital channels
November, 2008
System Feature Overview 17
• Color Code Free: This criteria is sometimes referred to as “Polite to Own Color Code” or
“Polite to Own System”, and is applied only to digital channels.
• Correct PL: This criteria is sometimes referred to as “Polite to Own System”, and is applied only to analog channels.
Channel access methods must be specified for each channel in the radio CPS. The TX (Transmit) parameters for each defined channel contains an “Admit Criteria” selection that must be set to one of the values described above.
All these channel access options govern how standard group voice calls and private calls access the system. Not all transmission types utilize these settings. For example, emergency voice calls always operate impolitely. This gives emergency voice calls a slightly higher priority over existing traffic on the channel. Data calls are always polite. Since a data call can be queued and retried, its priority is considered lower than voice.
Note that a “polite” radio user attempting a voice call will be polite to data, but an impolite user may not. Control messages (used for signaling features) are also always polite. The exception is the emergency alarm. Emergency alarms are sent with a mix of impolite and polite channel access, in order to optimize the likelihood of successful transmission.
When operating in IP Site Connect mode, the repeaters also check the channel for interference before transmitting. This is required since even though the source radio checks the channel at one site, it does not mean there is no interference at another site. Therefore, a repeater will check for over the air interference before waking up and transmitting. The repeater always acts with an
Admit Criteria of Channel Free and has a configurable signal strength threshold. Note that although one site may be busy, the other non-busy sites will continue with the call.
2.2.3.1 Impolite Operation (Admit Criteria of “Always”)
When configured for impolite operation, a radio does not check for an idle channel prior to allowing a transmission. From the user’s perspective, the radio simply transmits when the PTT is pressed.
However, on a digital repeater channel, the radio checks if the repeater is hibernating.
Transmission will not proceed, if the repeater is hibernating and the radio is unable to wake it.
NOTE: It is very important to note that when a radio is utilizing impolite operation, it is possible that it is transmitting on top of another user’s transmission. This causes RF contention at the target. When RF contention occurs between digital transmissions, it is impossible to predict which signal is usable. If one transmission is much stronger than the other, it is received instead of the weaker signal. But in most cases, the two transmissions on the same frequency and time slot results in both transmissions being unusable. Thus, it is recommended that only disciplined users are granted the right to use impolite operation.
Further, those impolite users are encouraged to utilize the busy channel LED on their radio to determine, if the channel is idle prior to transmitting.
When operating in IP Site Connect mode, it is important to understand that impolite channel access only occurs at the local site. If a call is taking place on the IP Site Connect system, and the original source of that call is at the same site as the interrupting “impolite” radio, RF contention will occur and it is unclear which source will be successful. If the original source of the call is at a different site from the interrupting radio, the original call continues at all other sites except where the interrupting radio is located.
November, 2008
18 System Feature Overview
2.2.3.2 Polite to All Operation (Admit Criteria of “Channel Free”)
When configured for Polite to All operation, the radio checks if channels are idle or busy, prior to allowing a transmission. The radio is polite to all analog or digital transmissions, another system’s transmission, or other traffic on your system. This option is often used, when there are neighboring communications systems, to prevent radio users from disrupting each other’s transmissions.
However, when this option is used, any strong signal on the channel blocks other users from transmitting.
2.2.3.3 Polite to Own Digital System Operation (Admit Criteria of “Color
Code Free”)
This criteria applies only to digital channels. When configured for Polite to Own Digital System operation, the radio checks for an idle or busy channel, prior to allowing a transmission. This operation is similar to the Polite to All operation with exception that the radio is not polite to analog systems or other system’s transmissions. It is only polite to other traffic in its own system. This option is often used when there are no neighboring communications systems, or when there is no concern about interfering with radios in neighboring communication systems.
2.2.3.4 Polite to Own Analog System Operation (Admit Criteria of “Correct
PL”)
This criteria applies only to analog channels. When configured for Polite to Own Analog System operation, the radio checks for an idle or busy channel, prior to allowing a transmission. This operation is similar to the Polite to All operation with exception that the radio is not polite to digital systems or other system’s transmissions.
2.2.3.5 Polite or Impolite While Participating in a Call (In Call Criteria)
The In Call Criteria applies only when the radio is participating in an active call. The radio can optionally allow others that are part of the call to transmit impolitely (Always) or to follow the previously configured channel access (Follow Admit Criteria). If configured for an In Call Criteria of
Always, the user will receive a Talk Permit Tone when they press the PTT while receiving a transmission for them. In otherwords, a radio has the ability to transmit over another user while listening to their transmission. However, when this happens, the other party does not stop transmitting and therefore RF contention can occur which may corrupt both transmissions. If configured for Follow Admit Criteria and the previously configured channel access (Admit Criteria) is set to either Channel Free or Color Code Free, the user will receive a Transmit Denial Tone when they press the PTT while receiving a transmission for them. Users must wait until the user stops transmitting and call hangtime starts before they are granted a transmission. Utilizing the
Channel Free Tone helps train users from transmitting too early. Although a setting of Always may be useful for speeding up conversations for well disciplined users, it may cause undisciplined users to “step over” other users. Therefore, it is recommended that most users are provisioned with an In Call Criteria of Follow Admit Criteria.
November, 2008
System Feature Overview 19
2.2.3.6 Repeater Wake-up Provisioning
When there is no inbound traffic for a specified duration (Subscriber Inactivity Timer), the repeater stops transmitting and enters an inactive state. In this inactive state, the repeater is not transmitting, but instead it is listening for transmissions. When the user or radio needs to transmit through the repeater, the radio sends a wake-up message to the repeater.
Upon receiving the wake-up message, the repeater activates and begins transmitting idle messages. The radio then synchronizes with the repeater before it begins its transmission.
The repeater wake-up sequence is configurable within the radio. The number of wake-up attempts
(“TX Wakeup Message Limit“) and the time between the attempts (“TX Sync Wakeup Time Out
Timer”) may be altered if required to operate with other vendor’s systems. It is recommended that these values remain at default while operating on MOTOTRBO systems.
November, 2008
20 System Feature Overview
2.3 MOTOTRBO Digital Features
2.3.1 Digital Voice Features
2.3.1.1 Group Calls
The digital group is a way of enabling groups to share a channel without distracting and disrupting one another. Because two-way radios are well suited for “one-to-many” types of calls, the Group
Call is the most common call in a MOTOTRBO system. Hence, the majority of conversations takes place within a group.
Individual radios that need to communicate with one another are grouped together, and configured to be members of a group. A transmitting radio can be heard by all the radios within the same group, and on the same logical channel (frequency and time slot.) Two radios cannot hear each other, if they are on the same logical channel (frequency and time slot) but on different groups.
Two radios on different logical channels cannot hear each other, even if they are placed in the same group.
In MOTOTRBO systems, capabilities for Group Calls are configured with the portable and mobile radio CPS. The repeater does not require any specific configuration for groups. Radios can be configured to enable the user to select among multiple groups using the radio channel selector knob or buttons, or using the radio menu contacts list. Which group a radio user hears on a given channel depends on a configurable parameter called the RX Group List. A call preceding tone can be provisioned to alert the target user of the incoming Group Call. This can be enabled or disabled
per Group. An introduction to configuring Group Calls and RX Group Lists is provided in “System
Design Considerations” on page 143 of this document.
Groups are defined according to the organizational structure of the end user. When planning for groups, customers should think about:
• which members of the functional workgroups in their organization that need to talk with one another,
• how those workgroups interact with members of other workgroups, and
• how users will collectively share the channel resources.
2.3.1.2 Private Calls
MOTOTRBO provides the capability for a user to place a Private Call (also known as an “Individual
Call”) directly to another radio, even if they are not in the same group. However, for this action to take place both radios need to be on the same channel and time slot. This feature allows a radio user to carry a one-to-one conversation that is only heard by the two parties involved. For example, an employee may use a Private Call to privately alert a specific manager about a security incident, rather than placing a Group Call that would be heard by the whole group. Though
Private Calls utilize the signaling capabilities in MOTOTRBO systems to govern which radios are allowed to participate, the use of a Private Call does not necessarily imply the use of encryption or scrambling.
November, 2008
System Feature Overview 21
Private Calls can be configured as confirmed or unconfirmed on a per channel basis. For confirmed private calls, the calling radio transmits a short control signal message to the target radio. This signaling verifies the presence of the target radio before being allowed to start the call.
The receiving user does not need to manually “answer” this signal, but rather the receiving radio automatically responds to the setup request. Once the receiving radio replies to the setup request, the initiating radio sounds a Talk Permit tone and starts the call. The receiving radio sounds a
Private Call indication to the user, prior to relaying the received voice. Once a Private Call is set up, subsequent transmissions do not require the call setup messaging. For unconfirmed private calls, the calling radio does not transmit any control signaling before being allowed to start the call.
Although there is no confirmation the radio is present on the system, an audible indication from the target user may act as confirmation. For example, “Joe are you there?”, “Yes, go ahead.”.
It is important to understand the advantages and disadvantages of confirmed and unconfirmed operation as it relates to performance. In general, confirming radio presence increases the setup time (voice access time) of a private call since the user must wait for the control signaling to go through the radio network before acquiring a talk permit tone. Although this may take more time, it does guarantee that the target radio is present prior to providing the talk permit tone. When operating on an IP Site Connect system that is connected through the public internet, this time may be longer than when operating on a single site since the control messaging may be traversing through the internet. If the target radio is scanning or roaming, the setup time of a confirmed
Private Call may increase due to the fact that the first control message may not successfully reach the scanning or roaming radio. The second attempt, which contains a preamble, has a higher likelihood of reaching the scanning or roaming radio.
Since unconfirmed Private Calls do not transmit any control signaling, the additional setup time is not required and therefore the voice access time is shorter. Because setup messaging is not used prior to starting the call, it is possible that scanning or roaming radios may arrive late to a call. This could cause the user to miss the first few words of the transmission (no more than what is lost while scanning for a Group Call). In addition, the user must utilize an audible acknowledgement to validate presence when configured with unconfirmed Private Calls since no control messaging is used to confirm radio presence.
In MOTOTRBO systems, capabilities for Private Calls are configured with the portable and mobile radio CPS. The repeater does not require any specific configurations for Private Calls. Radios can be configured to allow the user to select the recipient of a Private Call using the radio menu contacts list. Private calls can also be mapped to a channel selection or a programmable button.
Users can also manually dial the destination radio ID with the radio keypad. This means a radio can make a Private Call to any other radio that is on the channel, regardless of whether the radio has created a CPS Private Call entry for the target radio. A call receive tone, or call preceding tone, can be configured to alert the target user of the incoming Private Call. This can be enabled or disabled per individual radio. Greater detail on the fleetmapping process that governs who is allowed to make Private Calls and to whom, as well as an introduction to the CPS configuration
section for Private Calls, is provided in “System Design Considerations” on page 143 of this
document.
2.3.1.3 All Call
All Call is a one way voice call between a privileged operator and all users on a logical channel.
The transmitting radio utilizes a special All Call group that every radio on the same system and logical channel (regardless of group) will receive. Because this is considered a one-way transmission, users cannot talk back to an All Call. If the user transmits after receiving an All Call, he transmits using his currently selected group. An All Call follows the Admit Criteria of the
November, 2008
22 System Feature Overview
selected channel. More information on the Admit Criteria is provided in “Channel Access
All Calls do not communicate across different time slots or channels within the system. The ability to initiate an All Call is only programmed into radios that are used in supervisory roles. All other radios monitor All Call transmissions by default. This feature is very useful when a supervisor needs to communicate with all the users on a logical channel, rather than just a particular group or individual.
In MOTOTRBO systems, capabilities for All Calls are configured with the portable and mobile
CPS. The repeater does not require any specific configurations for All Calls. Radios can be configured to enable the user to select an All Call via the radio menu contacts list. All Calls can also be mapped to a channel selection or a programmable button. A call receive tone, or call preceding tone, can be configured to alert the target user of the incoming All Call. Greater detail on the fleetmapping process governs who is allowed to make All Calls, as well as an introduction to
2.3.2 Digital Signaling Features
We have already described how digital calls utilize digital vocoding and error correction coding processes, and that a given digital call occupies a single logical channel (frequency and TDMA time slot). Within a given time slot, the digital call is organized into voice information and signaling information. Included in the signaling information is an identifier used to describe the type of call that is transmitted within the time slot (e.g. group call, all call, or private call). Signaling information also includes identification information and/or control information, which is used to notify listeners on a voice call of system events and status (e.g. the ID of the transmitting radio and the group ID).
Because this information is repeated periodically during the course of the call, this embedded signaling allows users to join a voice transmission that is already in progress and still participate in the call. This is referred to as Late Entry, and is an advantage over analog signaling schemes.
2.3.2.1 PTT ID and Aliasing
This feature allows the target radio to identify the originator of a call. If programmed with the radio
CPS (Customer Programming Software), a user friendly alphanumeric name or “alias” can also be displayed. These user friendly aliases are also used when initiating voice calls and digital signaling features. The alias information in the transmitting radio should correspond with the alias information in the receiving radio. The transmitting radio ID is sent over the air and, if there is an alias for that ID in the receiving radio, the receiving radio displays the alias. If no alias is configured at the receiving radio for that ID, then only the transmitting radio's ID is shown.
2.3.2.2 Radio Disable (Selective Radio Inhibit)
This feature allows for a radio, typically in a supervisory role, to disable another radio via over the air signaling. The disabled radio's display blanks and the radio is no longer able to make or receive calls. The radio can still be turned on and off; this indicates that the radio has not failed, but is disabled. Once disabled, a radio can only be enabled via the CPS, or by a Radio Enable
(Uninhibit) command from another supervisor radio. All radios are configured to accept inhibit commands by default, but this can be disabled via the CPS. The target radio must be turned on and be within coverage of the site it was disabled at for this action to be completed successfully.
This is important when disabling radios that roam or scan since the radio locks onto the site or
November, 2008
System Feature Overview 23 channel on which it was disabled, even after a power cycle. It may be required to return the radio to the site in which it was disabled before it can receive an enable command over the air. This may also be accomplished by communicating with the radio on the talkaround frequency of the site in which it was disabled. The Radio Disable feature can be used to stop any inappropriate use of a radio, or to prevent a stolen radio from functioning.
In MOTOTRBO systems, Radio Disable is configured in the portable and mobile radios with the
CPS. To allow a radio to use this function, it must be enabled in the CPS “Menu” settings. To permit (or prevent) a radio from receiving and responding to this command, go to the “Signaling
Systems” settings in the CPS.
2.3.2.3 Remote Monitor
The Remote Monitor feature allows a remote user to activate a target radio’s microphone and transmitter for a period of time. A call is silently set up on the target radio, and its PTT is controlled remotely without any indications given to the end user. The duration that the target radio transmits after receiving a Remote Monitor command is set in the target radio through the CPS. When receiving the Remote Monitor command, the target radio initiates a Private Call back to the originator of the Remote Monitor command.
This feature is used to ascertain the situation of a target radio which is powered-on, but is unresponsive. This is beneficial in a number of situations including:
• theft,
• incapacity of the radio user, or
• allowing the initiator of an emergency call to communicate hands-free in an emergency situation.
In MOTOTRBO systems, Remote Monitor is configured in portable and mobile radio CPS. To allow a radio to use this function, it must be enabled in the CPS “Menu” settings. To permit (or prevent) a radio from receiving and responding to this command, go to the “Signaling Systems” settings in the
CPS. When a radio is configured to decode the remote monitor command, the duration that the target radio transmits after receiving a Remote Monitor command is also set in the CPS “Signaling
Systems” settings of the target radio.
The Remote Monitor feature may be activated on a disabled radio. Remote Monitor could also be programmed to be activated on radios that are in emergency mode only.
2.3.2.4 Radio Check
The Radio Check feature checks if a radio is active in a system without notifying the user of the target radio. Besides the Busy LED, there is no other audible or visual indication on the checked radio. The receiving radio automatically and silently responds with an acknowledgement to the initiating radio.
This feature is used to discreetly determine if a target radio is available. For example, if a radio user is non-responsive, Radio Check could be used to determine if the target radio is switched on and monitoring the channel. If the target radio responds with an acknowledgement, the initiator could then take additional action such as using the Remote Monitor command to activate the target radio’s PTT.
November, 2008
24 System Feature Overview
In MOTOTRBO systems, Radio Check is configured in portable and mobile radio CPS. To allow a radio to use this function, it must be enabled in the CPS “Menu” settings. All MOTOTRBO radios will receive and respond to a Radio Check, i.e. this feature cannot be turned off in the CPS.
2.3.2.5 Call Alert
The Call Alert feature allows a radio user to essentially page another user. When a radio receives a Call Alert, a persistent audible and visual alert is presented to the user. The initiator of the Call
Alert is also displayed. If a user is away from his radio at the time of the reception, the alert remains until the user clears the Call Alert screen. If the user presses the PTT while the Call Alert screen is active, he starts an Individual Call to the originator of the Call Alert. For in-vehicle applications, this is often used in conjunction with the Horn and Lights option. When a user is away from his vehicle, a Call Alert can initiate the vehicle’s horn and lights to sound and flash, which notifies the user to return to the vehicle and call the originator.
In MOTOTRBO systems, Call Alert is configured in portable and mobile radio CPS. To allow a radio to use this function, it must be enabled in the CPS “Menu” settings. All MOTOTRBO radios will receive and respond to a Call Alert (i.e. you cannot disable this feature by using the CPS).
2.3.3 Digital Emergency
MOTOTRBO offers a variety of emergency handling strategies that will fit the customer’s organizational needs. In its basic form, MOTOTRBO provides the ability for a radio user in distress to send a confirmed emergency alarm message, and emergency voice to a user on a supervisory radio. The emergency alarm message contains the individual radio ID of the initiator. Upon reception of an emergency alarm, the supervisor receives audible and visual indications of the emergency and the initiating radio ID is displayed. Depending on configuration, emergency voice may follow between the initiator and the supervisor. Once the supervisor handles the emergency situation (i.e. solves the problem), he clears the emergency on the supervisor radio. Once the initiator clears his emergency on the initiator radio, the emergency is considered over.
NOTE: A radio will not roam while reverted to a channel due to an emergency or when Active Site
Search is disabled. Reference the site roaming section for details on the interactions between emergency and roaming.
Each mobile radio can program the Emergency Alarm to any of the programmable buttons, whereas for the portable radio the Emergency Alarm can only be programmed to the orange button. The Emergency Alarm can also be triggered externally through a footswitch for a mobile application or any other applicable accessory. Pressing the emergency button causes the radio to enter emergency mode, and begin its emergency process.
When a user presses the Emergency button, the radio gives audible and visual indications to show that it has entered emergency mode. There is a CPS configurable option available, referred to as
Silent Emergency, which suppresses all indications of the emergency status on the user’s radio.
This feature is valuable in situations where an indication of an emergency state is not desirable.
Once the user breaks radio silence by pressing the PTT and speaking, the Silent Emergency ends, and audible and visual indications return.
When the user’s radio is in the emergency mode, various other features are blocked that may distract him from his communication with the supervisor. For example, the user will not be able to initiate other features such as scan, private call, or other command and control functions.
November, 2008
System Feature Overview 25
Once the emergency is complete (e.g. turn off and turn on the radio, or long press of emergency button), these abilities will return.
The emergency sequence is generally made up of two major parts:
• the signaling and
• the following voice call.
The emergency alarm is sent first, and depending on configuration is commonly followed up by an emergency call.
An emergency alarm is not a data service, but rather a confirmed command and control signaling that is sent to a group. More than one radio can be configured on the system to monitor that group, and be designated to acknowledge emergency alarms for that group. These radios are considered acknowledging supervisors. There is no user level acknowledgement. The supervisor radio automatically acknowledges the emergency, and provides an alert to the supervisor radio user.
There are other radios that are designated to only monitor emergency alarms, but are not permitted to acknowledge them; these users are commonly referred to as non-acknowledging supervisors. Thus, sending the emergency alarm to a group allows for multiple supervisors to receive the emergency alarm indication. It is important that only one acknowledging supervisor should be configured per group and slot; otherwise there may be contention between the acknowledgements.
The supervisors retain a list of received emergency alarms so that they can keep track of multiple emergencies. Once cleared, the emergency alarm is removed from the list, and the next one is displayed. These emergencies are displayed in a last-in-first-out sequence. The supervisor has the ability to hide the emergency alarm list, so he can contact service personnel to attend to the received emergency situation. The channel where the emergency alarm was received is displayed to aid the supervisor when changing channels.
If the user follows up the Emergency Alarm with a voice call while in the emergency mode, his transmission contains an embedded emergency indication. Any radio user can be configured to display this embedded emergency indication. Emergency calls are always processed with an admit criteria of Always. This allows the emergency call to transmit regardless of the current channel activity. If there is another radio currently transmitting, contention may occur.
The initiating radio supports a feature that is tied to silent emergency and the emergency call. The
“Unmute Option” prevents the radio from receiving voice traffic after initiation of a Silent
Emergency. In situations where an indication of an emergency state is not desirable, it is important to be able to mute incoming voice, that may give away the initiators emergency state. Once the user breaks radio silence by pressing the PTT and speaking, the radio returns to its normal unmute rules.
Silent emergency and the unmute options have 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 Silent Emergency.
The channel and group on which a user transmits his emergency is crucial to properly contacting a supervisor. MOTOTRBO offers the ability for a user to transmit the emergency on a selected channel or to automatically change to a predetermined channel to transmit his emergency.
November, 2008
26 System Feature Overview
Transmitting an emergency on a selected channel (referred to as a “tactical” emergency) is often useful on small systems where there are only a few groups of users. Each group has its own specified user that handles emergencies.
Automatically changing to a predetermined channel, referred to as “reverting”, is often useful in systems that have a dispatch style emergency strategy. Users in various groups and channels are configured to revert to a specific channel and group to process an emergency. This allows one user to monitor an “Emergency” group, and all other users revert to him in case of an emergency.
This minimizes the possibility of supervisors missing emergencies on one channel, while monitoring another channels. After the emergency is cleared, all users revert back to the selected channel they were on before the emergency. In MOTOTRBO systems, the Emergency Revert
Channel is configured in portable and mobile radio CPS at the Digital Emergency Systems settings.
There are three major methods to process the emergency alarm and the emergency call; all are configurable through the CPS. They are Emergency Alarm Only, Emergency Alarm and Call, and
Emergency Alarm with Voice to Follow.
2.3.3.1 Emergency Alarm Only
When configured for Emergency Alarm Only, the emergency process only consists of the emergency alarm part. The number of emergency alarm attempts and their admit criteria are configurable, and can even be set to retry indefinitely. The number of alarm attempts are controlled by CPS parameters in the Digital Emergency System settings; these parameters include the number of polite and impolite retries. The alarm is initially sent regardless of channel activity, and once the configured impolite attempts are exhausted, the polite retries are executed when the channel is idle. Emergency ends when:
• an acknowledgement is received,
• all retries are exhausted,
• the user manually clears the emergency, or
• the user pushes the PTT.
No voice call is associated with the emergency when operating as Emergency Alarm Only.
Pressing the PTT clears the emergency, and a standard voice call is processed.
2.3.3.2 Emergency Alarm and Call
When configured for Emergency Alarm and Call, the emergency consists of the emergency alarm process followed by the ability to perform an Emergency Call. The number of emergency alarm attempts and their admit criteria are configurable, and can even be set to retry indefinitely. The alarm is initially sent regardless of channel activity, and once the configured impolite retries are exhausted, the polite retries are executed when the channel is idle.
Emergency alarm stops when:
• an acknowledgement is received, or
• all retries are exhausted.
The radio still remains in an emergency state. Any follow up PTT initiates an emergency call, and the call includes an embedded emergency indication. If the user presses the PTT before the radio
November, 2008
System Feature Overview 27 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 he manually clears emergency. The only way to reinitiate the emergency alarm process is to reinitiate the emergency.
2.3.3.3 Emergency Alarm with Voice to Follow
When configured for Emergency Alarm and with Voice to Follow, the emergency consists of sending a single emergency alarm, and followed by an automatic transmission of an Emergency
Call. This is referred to as hot microphone. The radio only sends one emergency alarm regardless if there is 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. The duration of the hot microphone state is configurable through the CPS in the Digital
Emergency Systems settings. This 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 the emergency mode. Any follow up PTT initiates an emergency call, and includes the embedded emergency indication. The user remains in the emergency mode until he manually clears his emergency. The only way to reinitiate the emergency alarm and the hot microphone is to re-initiate the emergency.
It is important to note that when configured for Emergency Alarm with Voice to Follow, the radio will continue to transmit voice for the duration of the provisioned hot microphone timer. Since voice has priority over data, any data is queued while voice is transmitting, including the GPS update that was triggered by the emergency. The GPS data cannot be delivered until after the radio stops transmitting voice, and after the repeater hangtime has expired. The GPS data has no additional priority over other data queued in the radios, or over any traffic on the channel. Therefore, its delivery may be delayed if the radio in emergency has pending data queued or if the channel is busy processing other traffic.
It is recommended when utilizing Emergency Alarm with Voice to Follow and GPS, that the hot microphone timer be at maximum 30 seconds. There are a few reasons for this. First of all, data messages will not stay in the queue for ever, 30 seconds is short enough so to give the GPS data a chance to be transmitted without timing out. Second, if the hot microphone timer is longer than
30 seconds, and the GPS update rate is around the same value, then other GPS messages may start to fill up in the queue while the voice transmission is processing. This not only occurs with the radio in emergency, but with all other radios since the channel is busy. Therefore when the voice call ends, all radios will be attempting to access the channel with their GPS data which increases the likelihood of collisions and lost messages. Finally, it is important to understand that while the user is transmitting due to its hot microphone timer, there is no way to communicate back to him.
Most users can explain their situation in less than 30 seconds and require some feedback from the emergency dispatcher much sooner. That is why it is recommended to keep this value low and if additional monitoring is required, the remote monitor feature can be utilized. Only use a long hot microphone timer in specialized applications.
Also, since the emergency alarm itself is not acknowledged nor retried, its reliability is less than that of the standard Emergency Alarm and Emergency Alarm Only and Call. These considerations should be taken into account when choosing to operate with Emergency Alarm with Voice to
Follow.
November, 2008
28 System Feature Overview
2.4 MOTOTRBO Integrated Data
2.4.1 Overview
When performing in digital mode, any MOTOTRBO radio can be used as an integrated voice and data radio, where the radio can send voice as well as data messages on a given logical channel.
This does not refer to data services like enabling users to surf the web, send video images, or synchronize their office desktops. This is not the right technology for such bandwidth-hungry applications. However, it is a great technology for productivity-enhancing applications like messaging, location based services, simple database queries, bar code reading, and fill-in-theform type of applications. Additionally, it is built into the MOTOTRBO system, so there are no monthly fees or dependencies on public carrier services, and customers control what applications their users can access.
The MOTOTRBO system provides reliable data communications throughout the same areas where the system provides readily usable voice communications. However, there is a trade-off between the desired RF coverage area for data and the data throughput of the system. Extending the range of a system's operation requires more data message retries to successfully complete confirmed transactions, thus lowering throughput.
Integrating voice and data on the same channel brings several benefits. These include:
• Use of one RF channel for both voice and data.
• Use of one system infrastructure for both voice and data.
• Use of one subscriber to send and retrieve both voice and data messages over the air.
Integrating voice and data on the same channel also brings several considerations. These include the following:
• Traffic loading
• Customer application requirements
• Contention of voice and data.
“System Design Considerations” on page 143 of this document provides practical guidance on the
above considerations.
MOTOTRBO supports data services in a number of ways.
• MOTOTRBO contains a built-in text messaging service that allows radios to send “unit-tounit” and “unit-to-group” messages directly from the user interface of the radio.
• MOTOTRBO also enables infrastructure and/or PC based applications by supporting
Internet Protocol (IP) addressing and IP packet data services. Rather than relying upon external modems, MOTOTRBO radios can connect directly to computer equipment with standard USB interfaces. This simplifies and lowers the cost of integrating with applications, and at the same time expands the universe of potential applications that organizations can deploy. Depending upon availability in your region,
Motorola offers two PC based MOTOTRBO applications.
November, 2008
System Feature Overview 29
• MOTOTRBO supports a Third Party Application Partner Program. This program includes a complete application developer’s kit that fully describes interfaces for IP data services, command and control of the radio, and for option boards that can be installed in the radio.
For some infrastructure based data applications, the radio must first complete a registration process before data messages can be exchanged between the radio and the infrastructure based application. Registration has no impact on voice operation, aside from utilizing the same channel.
Polite voice calls will have to wait until an in-progress registration completes before it can use the channel, while impolite voice calls can transmit on top of a registration transmission. A radio does not have to register for voice services. A radio registers when the radio powers up in a data capable mode, or changes into a data capable mode. A radio registers with a Presence Notifier, which is incorporated within the third party applications. The Presence Notifier informs the data application servers that the registered radio is “on the system” and available for services.
In MOTOTRBO systems, the codeplug configuration determines whether or not a radio attempts to register on the selected channel. This is defined via the ARS parameter which is enabled or disabled through the settings within each channel. It must be set to enabled for those channels that are utilized for data communications with infrastructure based applications.
November, 2008
30 System Feature Overview
2.4.2 Text Messaging Services
Multiple MOTOTRBO system components interact together to deliver text messaging services.
These include the built-in text messaging capabilities of MOTOTRBO subscriber radios and the third party text messaging applications. The services provided by each of these components are described in the following subsections.
Figure 2-8 Text Messaging Services
Figure 2-8 shows a sample MOTOTRBO Text Messaging system configuration. See “System
Components and Topologies” on page 93 for more details on setting up your MOTOTRBO system.
2.4.2.1 Built-In Text Messaging Service
The built-in text messaging feature allows MOTOTRBO portable and mobile radio users to send and receive information in a text format. This feature provides a useful alternative to voice on the
MOTOTRBO system. The built-in text message service is fully accessed from the menu system on
MOTOTRBO radio models with keypads and displays. Some aspects of this service are also available to non-display models.
2.4.2.1.1 Services Provided to a Radio User
Using the built-in text messaging services, a radio user can create, send, receive, store and display a text message. The following capabilities are included:
November, 2008
System Feature Overview 31
• A radio user can create a text message in one of two ways: Quick text or limited free-form text messages. Quick text messages are pre-defined using CPS. This allows a user to choose from commonly sent messages without having to retype the content. Once selected, the user is allowed to edit any part of the Quick text message prior to sending. The CPS allows you to define 10 Quick Text messages.
• A radio user can select to send a text message to other radios. Messages can be sent to an individual or to a group. When a message is sent to an individual, the sender receives an acknowledgement once the recipient receives the message. If all delivery retry attempts were exhausted, a failure indication will be generated. With messages addressed to a group, the sender only receives confirmation that the message was transmitted and does not receive confirmation from any of the intended recipients.
• When receiving a text message, the user is notified of a new message by an icon, display string, and an audible tone if enabled in the codeplug via the CPS.
• Messages are received only if the radio is currently in digital mode of operation. A radio user should enter scan mode to receive messages if multiple channels are being utilized. System
planning considerations associated with data and scan are discussed in “System Design
Considerations” on page 143 of this document.
• A user can store up to 30 received or sent text messages at a time. The user is notified once the Inbox and sent folder storage becomes full. Once full, subsequent new messages automatically cause the oldest messages to be deleted. Messages are not deleted when the radio is turned off.
• The user can scroll through messages and select any message to read, reply to, forward, save or delete.
2.4.2.2 Services Provided to a Third Party Text Message Application
Motorola provides an Application Development Kit (ADK) which documents how a text message application interfaces with the text message protocol used for MOTOTRBO. A list of available
ADKs is available on page 89 of this manual.
November, 2008
32
2.4.3 Location Services
System Feature Overview
Figure 2-9 Location Services
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 alone (latitude/longitude) or the location combined with other information about the environment (horizontal speed, direction, etc.) that allows value-added services, such as tracking of resources.
MOTOTRBO systems enable location services via two complementary functions. First, the
MOTOTRBO mobile and portable radio portfolio includes models that are equipped with a built-in
GPS receiver. The acquisition of location data is done by a GPS receiver inside the radio and is dependent on the GPS receiver receiving accurate signals from the earth-orbiting Global
Positioning System (GPS) satellites. However, the GPS receiver may not work well indoors or in environments where the sky is largely obscured. Using the integrated data services capability of the MOTOTRBO system, GPS equipped mobiles and portables are able to transmit their location coordinates, over the radio system, to a receiving application that displays the radios’ geographic locations on a high resolution map. This third party receiving application is the second part of the system.
MOTOTRBO provides a location interface to third party location services applications For more
information regarding third party applications, please see “Third Party Application Partner
November, 2008
System Feature Overview 33
2.4.3.1 Performance Specifications
GPS Transmitter Portable Mobile
TTFF (Time to First Fix) Cold Start
TTFF (Time to First Fix) Hot Start
< 2 minutes
< 10 seconds
< 1 minute
Horizontal Accuracy < 10 meters
Note: Accuracy specifications are for long-term tracking (95th percentile values > 5 satellites visible at a nominal -130 dBm signal strength).
The definitions for some of the terms stated in the table above are as below:
• 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 realtime 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), as well as, 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.
• Horizontal Accuracy – Horizontal Accuracy indicates a radius length from the reported point location. The latitude and longitude reported is equivalent to a point in the center of a circle, with the horizontal accuracy value as the radius of the circle. The true position should be within this location range.
November, 2008
34 System Feature Overview
2.4.3.2 Services Provided to a Radio User
When the location service is disabled, the radio does not provide any location updates to a location application server. An icon is displayed on the radio if the location service is enabled. The absence of this icon indicates that the location service is disabled. The icon shows a full satellite dish when good GPS signals are detected and an empty satellite dish when the radio is receiving poor GPS signals.
Good Signal Poor Signal Disabled no icon
The radio does not display its current location on its screen. 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; the radio transmits the location coordinates automatically over the system.
2.4.3.3 Services Provided to a Location Application
For all the services, a third party 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 and/or selects a properly configured channel (i.e. the previously mentioned “ARS Parameter”), the radio registers with the presence service. The location application thus 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 GPS equipped radios transmit an update of their location coordinates over the radio system in response to 3 service methods.
• 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.
• Periodic Location Updates – 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. 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. The location tracking application can configure the radio to provide updates as frequently as once every 10 seconds. The default value is once every 10 minutes. The rate of update is configurable in increments of 1 second and must be matched with the resource capabilities of the radio system and the needs of the
end-user. This is discussed further in “System Design Considerations” on page 143.
November, 2008
System Feature Overview 35
• 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.
November, 2008
36 System Feature Overview
2.4.3.4 GPS Revert Channel
The GPS Revert Channel feature allows system operators a configurable option to off load radio transmitted location updates onto a pre-programmed digital channel that differs from the digital
Selected Channel. This feature effectively removes Location Update traffic from the Selected
Channel in order to free up that channel to accommodate increased voice loads and/or to enhance the user experience by reducing the number of channel busies during voice call requests. This feature also allows a large group to communicate on a single voice channel while sending location updates on multiple GPS Revert Channels to accommodate larger Location Update loads. This increases the Location Update throughput associated with radios belonging to a single group.
Each channel programmed into the radio has a configurable CPS option to designate the GPS transmission channel on which it transmits Location Update messages. The CPS options for the
GPS transmission channel are Selected, All, and None. Choosing Selected means that the GPS updates are transmitted on the current channel. In the case of All, a single channel must be chosen from the list of all channels. This chosen channel is known as the GPS Revert Channel and this is where GPS updates are transmitted on. It is understood that there may be instances when the radio is known to be out of range of any control station accepting location updates. In order to extend battery life, minimize time away from the Selected Channel, and/or to efficiently use frequency resources in these situations, the radio can also be configured to disable the transmission of Location Update messages on a per channel basis by using the selection None. It should be noted that a radio will be shown as present to the dispatcher when a radio is switched from a GPS enabled channel to a GPS disabled channel until the presence indication duration is exceeded.
To configure the radio to support location updates, there are a few parameters that must be managed correctly. How these parameters interact to dictate the radio’s performance is shown in the table that follows. These parameters are the radio wide GPS setting that resides in the General
Settings CPS folder, and the ARS and GPS Revert settings that are present for each channel defined in CPS. In this case the channel being defined is titled “Channel1”. Also, in the case where a GPS Revert Channel (GPS1) is selected, this requires that GPS1 has already been defined as a channel in CPS.
General
Settings: GPS
Channels:
Zone1
Channel1
ARS
Channels:
Zone1
Channel1
GPS Revert
Result
Not Enabled
Not Enabled
Enabled
Not Enabled
Enabled
Not Enabled
Not Selectable
Not Selectable
Not Selectable
GPS Chip: Disabled
Presence: Disabled
Location: Disabled
GPS Chip: Disabled
Presence: Enabled
Location: Disabled
GPS Chip: Enabled
Presence: Disabled
Location: Disabled
November, 2008
System Feature Overview 37
General
Settings: GPS
Channels:
Zone1
Channel1
ARS
Channels:
Zone1
Channel1
GPS Revert
Result
Enabled Enabled None
Selected (Channel1)
GPS Chip: Enabled
Presence: Enabled
Location: Disabled
GPS Chip: Enabled
Presence: Enabled
Location: TX on Channel1
Enabled Enabled
GPS1
GPS Chip: Enabled
Presence: Enabled
Location: TX on GPS1
Note: Not Selectable means the setting cannot be configured as the option is grayed out.
2.4.4 Telemetry Services
The MOTOTRBO radios incorporate telemetry functionality that is only supported in the digital mode of operation. Both the MOTOTRBO portable and mobile radio support General Purpose
Input/Output (GPIO) lines on the radio accessory connector.
With this telemetry functionality, the originating radio can send a telemetry command to another radio at the press of a programmable button. Telemetry commands instruct GPIO pins on the target radio to be set, clear, toggle or pulse. The telemetry commands can also be used to query the status of GPIO pins at the target radio.
At the receiving end, the basic built-in telemetry functionality allows the target radio to translate the received telemetry command and to trigger GPIO action. It also enables the target radio to display a pre-programmed Text Status Message or act on a telemetry command received from the originating radio responding to an event at the originating radio's GPIO pins. The Telemetry Text
Status Message is provisioned in the source telemetry radio and is displayed as a popup alert at a target radio via the telemetry application. Since the Telemetry Text Status Message is not sent as a standard text message, it is not saved in the Inbox or indexed. Furthermore, its target can only be another radio since it must be received and processed by the telemetry application within the radio.
It is possible for the message to be forwarded to an external computer connected to the radio, or the option board, where a customer supplied application could monitor and take an action.
MOTOTRBO provides a telemetry interface for third party telemetry applications. Further
information is available in the Telemetry Services ADK listed under “MOTOTRBO Documents
Available via the Third Party Application Partner Program” on page 89.
Telemetry over-the-air signaling utilizes the data service similar to the way that text messaging works. It can co-exist with voice and text messaging. If telemetry messages are expected to occur often, for example 30 radios sending telemetry once every 5 minutes, this may affect performance of other services on the channel. This should be taken into consideration when determining the data load versus quality of service of a channel.
November, 2008
38 System Feature Overview
2.4.4.1 Physical Connection Information
The MOTOTRBO portable offers three GPIO pins, and the MOTOTRBO mobile offers five GPIO pins for telemetry. These GPIO pins can be set to high or low, toggled, or pulsed for a configured duration. A pin can be configured to be active high or active low. It is recommended to use an ACpowered MOTOTRBO mobile for most extended telemetry applications. Motorola does not currently offer external hardware for telemetry configuration.
The GPIO lines have a 4.7k ohm pull-up resistor tied to a regulated 5 V
DC
supply within the mobile radio. The regulated supply remains on as long as power is supplied to the mobile, even if the mobile is turned off so the pull-ups are active even when the radio is off.
When configured as input, the voltages of the GPIO lines should be within the range of 0 V
DC
to
5.5 V
DC
.
• 0 V
DC
to 0.8 V
DC
are interpreted as low level
• 2.2 V
DC
to 5.5 V
DC
are interpreted as high level
When configured as output, the GPIO will be able to source a current of 1mA maximum at the following levels:
• 4.7 V
DC
to 5.5 V
DC
for a high level
• 0 V
DC
to 0.8 V
DC
for a low level
2.4.4.2 Telemetry Examples
See section 3.2.1.1.2 and section 3.2.2.1.2 for diagrams and descriptions of the following simple telemetry examples in both direct and repeater mode.
• Send Telemetry Command from Radio to Another Radio to Toggle an Output Pin
• Send Telemetry Message from Radio to Another Radio when Input Pin State Changes
• Send Telemetry Command to Toggle an Output Pin from Radio to Another Radio when Input
Pin State Changes
November, 2008
System Feature Overview 39
2.5 Scan
MOTOTRBO supports scanning of analog voice, digital voice, data, and digital signaling through a repeater or directly from another radio. When scanning, the radio continuously searches a list of channels for activity of interest. When activity of interest is found, the radio stops and switches to that channel. When finished, the radio continues scanning the channels in the list.
The set of channels to be scanned (or scan members) are determined by a configured Scan List. A radio can have multiple Scan Lists, and each channel in a radio can be associated with a different
Scan List. Scan Lists can contain only analog channels, only digital channels, or a mixture of both analog and digital channels. Once scan is started, the radio scans through each scan member of the associated Scan List for the selected channel.
The CPS allows a user to create, edit, or delete scan members in a Scan List, as well as associate a Scan List to a channel. The user can start or stop scan, and also add or remove scan members of a Scan List using the radio’s interface. Changes to the Scan List made by the radio are persistent until the radio is turned off. Note that Scan and Roam are mutually exclusive on a channel within CPS.
When the radio is scanning, and it detects a digital scan member in its Scan List, it looks for transmissions targeted towards the group(s) associated with that channel. The radio also looks for transmissions targeted towards itself (e.g. private calls or signaling commands). The radio can be configured such that replies that occur within a specified duration is transmitted to the same group and channel (this reply is called talkback). If the reply occurs outside of this duration, it is considered a new transmission.
There are also options for where new voice transmissions (outside of the previously mentioned duration) are transmitted while scanning. Voice can be configured to transmit on the selected channel (the channel from which scan was started), another predetermined channel, or on the last landed channel for voice (the last channel that scan “locked-on-to”). Data and digital signaling are always transmitted on the selected channel. The last landed channel is not updated for data and digital signaling.
Priority levels can also be configured for members of a Scan List. There are three levels of priority within a scan list – Priority-1, Priority-2, and Non-Priority. The Priority-1 and Priority-2 channels are scanned more often than the Non-Priority scan members. Priority scan is available with any mix of analog, digital, talkaround or repeater channels.
The Scan List can be configured to have one Priority-1 member and one Priority-2 member; the remaining are considered Non-Priority. When scanning, these priorities affect the order of scanning. The following represents the scan order of Scan List: Priority-1, Priority-2, Non-Priority-
1, Priority-1, Priority-2, Non-Priority-2, Priority-1, Priority-2, Non-Priority-3, etc. However, the radio may reorder Non-Priority scan members in order to optimize the efficiency of the scan.
In the CPS, there are two parameters associated with scan lists - Set/Clear Priority-1 and Set/
Clear Priority-2. These are used to mark a scan list member as Priority 1 and Priority 2; unmarked list members are “non priority”.
While scanning, the radio can accept data (e.g., text message, location, telemetry, or terminal (PC) data). However this is only applicable if the data is received on its selected (home) channel.
November, 2008
40 System Feature Overview
NOTE: In MOTOTRBO radio’s with software versions R04.00.00 or later, various enhancements were made to the scan engine to improve scanning performance. This has caused some features, such as scanning for Group Text Messaging and Emergency Alarms, to no longer be backward compatible with older software versions. All equipment must be upgraded for these features to perform correctly.
2.5.1 Priority Sampling
When scanning, if some activity of interest is found, the radio stops and switches to that channel. If the activity of interest is incoming data addressed to the scanning radio, an individual voice call, or it is on a Priority-1 scan member, scanning completely stops for the duration of the call. But if the activity is a voice group call on a Priority-2 or a Non-Priority scan member, the radio continues to periodically scan higher priority scan members.
For example, if the radio is receiving voice on a Non-Priority scan member, then the Priority-1 and
Priority-2 scan members are scanned periodically. In this case, the order of scan will be: Priority-1,
Priority-2, Priority-1, Priority-2, etc. If the radio is receiving voice on a Priority-2 scan member, then only the Priority-1 scan member is scanned periodically. If a transmission of interest is found on the higher priority member, the radio switches to that member to monitor the transmission. If it is not of interest, it returns to the previously monitored member. Priority Sampling does not occur when transmitting.
Because the radio is currently receiving voice, leaving the current scan member to scan a higher priority member will cause the radio to temporarily leave the current transmission. This causes an audio hole in received audio that is being played through the radio’s speaker. Thus, the intervals during which the radio samples the higher priority members, essentially, becomes the audio holes that are introduced into the currently monitored voice. If there are two priority channels configured, this time is how often a sample is taken of either one. Therefore, one particular channel is sampled at a rate of double the priority sampling duration. A balance between how often an audio hole is introduced and how often a channel is sampled needs to be achieved to ensure that transmissions are not missed and to prevent introducing too many audio holes. This interval is CPS configurable via the “Priority Sample Time” interval parameter. Since the radio only samples at the rate of the
Priority Sample Time, it is important to understand that if sampling for data, the Scan Preamble must be set to double the Priority Sample Time.
The user experiences few to no audio holes if he is currently unmuted to a lower priority voice while the priority member is in the other timeslot of the same repeater. In this situation, the radio uses the embedded signaling in the repeater to monitor activity in the other timeslot. This should be taken into consideration when deciding which identifiers are assigned to which channels and slots.
Not all identifiers are uniquely identified in the embedded signaling because they are compressed into smaller identifiers. If the system contains two or more identifiers that share the same compressed identifier, the radio incurs additional audio holes to validate the actual uncompressed identifier matches.
Duplicate compressed identifiers can be avoided if kept within a 256 ID range where the first ID of the range is an integer multiple of 256. For example if group and individual identifiers are kept between 0 and 255, or 256 and 511, or 512 and 767, etc., they will have unique compressed identifiers and no audio hole will be experienced while priority sampling the other timeslot.
November, 2008
System Feature Overview 41
Setting a busy channel as a priority channel can cause excessive audio holes in non-priority audio as the radio checks each new transmission on the priority channel to determine if it is call of interest. If the priority channel has many short transmissions that are not of interest, the radio will be forced to incur at least one audio hole for each. Therefore, it is recommended, that if possible, high priority transmissions should be isolated on channels that are not overly utilized by other traffic.
2.5.2 Channel Marking
In addition to configuring the sampling interval for Priority Sampling, MOTOTRBO offers a way to mitigate the duration of the audio hole itself with a feature called Channel Marking. Although relatively short, it does take time to determine if a transmission is of interest on a particular scan member. During this time, there is an audio hole in the scanned audio.
The Channel Marking feature introduces logic that assumes that if a transmission was recently identified as not of interest, there is no need to fully review it at every scan interval. Additionally, if the type of transmission is of the same type as the transmission identified as not of interest before, there is a high likelihood it is the same transmission. Therefore, the radio only needs to identify the type of transmission taking place, which is beneficial as identifying a transmission type takes much less time than fully identifying if a transmission is not of interest. This assumption is made for a pre-determined number of times, after which, the scan member is fully reviewed again. This method changes the experienced audio holes from long audio holes every priority scan interval to one long audio hole followed by numerous short audio holes, and then another long audio hole, and so on.
This feature can greatly increase audio quality while a radio is in priority sampling mode. The drawback to channel marking is the assumption that the target of a transmission has not changed.
The scanning radio will not know if the target has changed until the next full inspection. The system should be configured in such a way using CPS parameters to achieve a balance which delivers improved audio quality without sacrificing too much flexibility to consistently locate new transmissions which otherwise would be of interest. It is recommended that Channel Marking is set as Enabled in most scenarios.
However, if there is an analog signal on a digital priority channel, the radio will incur a medium size audio hole on every sample even if channel marking is enabled. The radio spends this time searching for synchronization that is not present. It is recommended that the priority traffic be placed on a channel that has limited analog interference (i.e. shared use).
2.5.3 Scan Considerations
The ability to scan multiple channels is an advantage when a user must be aware of activity on numerous channels. MOTOTRBO offers the ability to scan a list of analog and digital channels
(frequency and slot) within the same scan list (often referred to as a Channel Scan List). This feature is incredibly useful when planning to migrate from analog to digital, or when a user must monitor multiple repeater frequencies and slots at the same time. When operating in digital,
MOTOTRBO also provides the ability to scan multiple groups on a channel (slot). This is often referred to as a Group Scan.
A Group Scan is an optimized way to scan for multiple groups on the same channel (slot). The radio monitors the channel from either the repeater or directly from another radio to determine which group is currently transmitting. If the group transmitting is one specified in the Group Scan
List, the radio will stop and listen. The radio is allowed to talkback to the group for the duration of
November, 2008
42 System Feature Overview the call hang time. This call hang time overrides the TX Contact Name setting of the channel.
Because only one call takes place on a channel (slot) at any given time, the scanning radio will not miss a transmission of interest, regardless of the length of the group list. A Group Scan is configured by creating a group list and adding groups already in the Contacts folder. This group list can then be selected as the RX Group List of a particular Channel. The Group Scan does not have the advanced features and configuration options of a channel scan. For example, once configured via CPS, the Group Scan cannot be turned on or off and members cannot be added or removed.
Furthermore, the configurable scan options (Scan Hang time Timer, Talkback, etc.) do not control the Group Scan. The Group Scan should be used in simple systems where no advanced scan options are required. If advanced scan options and features are required, a Channel Scan should be configured instead.
A Channel Scan will scan a list of different channels within a system – analog or digital. A Channel
Scan is different from a Group Scan since the radio must change frequencies and sometimes even modulations (analog to digital) in order to scan for activity. Unlike a Group Scan where only one call occurs at any given time, when scanning different channels (analog or multiple digital slots), there can be calls taking place on any or all of the channels. Because the radio cannot be everywhere at once, there is a possibility that the radio will miss a transmission of interest.
Because of this, it is recommended that the number of channels in a Channel Scan list is kept to a minimum. The larger the scan list, the more likely a user will miss, or join late, a transmission of interest during busy times.
2.5.3.1 Scanning and Preamble
Since data and digital signaling messages are typically shorter in duration than voice transmissions, it can be difficult for a scanning radio to detect such messages. This is especially true as the number of scan list members increases because the amount of time between a scanning radio’s repeated visits to a particular scan list member increases, making it less likely to be on the channel at the exact moment that the data or digital signaling message begins. Another factor is the amount of activity on each scan list member; basically, the more active each scan list member is, the more likely that the radio is suspending its scan operations to receive on each of those scan list members, further increasing the likelihood that the radio will not receive the data or digital signaling on another scan list member. To improve the likelihood of receiving data and digital signaling messages, the duration of these message types can be extended by preceding the message with special preamble signaling. The amount of preamble signaling to use can be configured into the initiating radio and the amount of preamble to use is dependent upon the number of scan list members in the target radios’ scan list and whether priority scan is being used.
Since this added signaling increases the amount of airtime used for data and digital signaling messages, there is a trade-off between increased channel loading and increased likelihood of receiving data and digital signaling messages while scanning.
November, 2008
System Feature Overview 43
Suggested guidelines for the amount of preamble duration to use with scan lists not using priority is provided in the following table.
Number of Analog Scan List Members
0
1 -
-
-
-
2
3
4
5
720 960 960 960 1200 1200 1200 1200 1440 1440 1440 1680 1680 1680
960 960 1200 1200 1200 1200 1440 1440 1440 1680 1680 1680 1680
960 1200 1200 1200 1440 1440 1440 1680 1680 1680 1680 1920
6 1200 1200 1440 1440 1440 1680 1680 1680 1680 1920 1920
7 1200 1440 1440 1680 1680 1680 1680 1920 1920 1920
8 1440 1680 1680 1680 1920 1920 1920 1920 2160
9 1680 1680 1920 1920 1920 1920 2160 2160
-
- - 10 1680 1920 1920 1920 2160 2160 2160
-
11 1920 1920 2160 2160 2160 2400
12 1920 2160 2160 2400 2400
-
- -
13 2160 2400 2400 2400
-
14 2400 2400 2640
15 2400 2640
- -
-
-
-
-
16 2640
- - -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
The preamble duration should be increased when scan list members tend to carry lots of traffic or long transmissions. If no radios in the system will use the scan feature, then the amount of preamble may be set to zero.
The preamble duration also should be increased when priority scan is being used. Since the preamble signaling is used in conjunction with data and digital signaling messages, and directmode, and since digital-only scan lists support both priority scan and data and digital signaling messages, the following table suggests guidelines for the amount of preamble duration to use with direct-mode, digital-only scan lists using priority.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
November, 2008
44 System Feature Overview
12
13
14
15
16
10
11
8
9
6
7
4
5
2
3
0
1
Number of Priority Members
0
-
1
-
2
-
1680
1680
1920
1920
2160
2400
2400
2640
960
1200
1200
1440
-
480
720
960
3360
3360
3840
3840
4320
4800
4800
5280
-
960
1440
1920
1920
2400
2400
2880
4800
4800
5520
5520
6240
6960
6960
7680
-
1200
1920
2640
2640
3360
3360
4080
If data and digital signaling is not carried on any of the non-priority channels and is only carried on one of the priority channels (which must be the selected channel for data messages), then the amount of scan preamble to use can be as specified in the first row of the Priority Scan table, above, regardless of the number of non-priority scan list members.
2.5.3.2 Channel Scan and Last Landed Channel
A Channel Scan can be configured by selecting a group of already configured channels within a radio using the CPS, and adding them to a Scan List. Each channel is then configured to use this
Scan List of channels. When scan is activated on a channel that contains a Channel Scan List, the
MOTOTRBO radio checks for activity on each of the channels on the list.
While scanning a digital channel for activity, all Groups specified in the channel’s RX Group List will be monitored.However if the radio is configured with a Channel Scan that contains channels that are configured with a RX Group List (a Group Scan), then only the Last Landed Channel is remembered by the radio, not the Last Landed Channel and Group. This means that voice transmissions are transmitted on the TX Call Member configured for the channel that was the Last
Landed Channel, not the Group in the Receive Group List of channel that was the Last Landed
November, 2008
System Feature Overview 45
Channel. Note that if a transmission is made within the call hang time of the scanned transmission, it will be targeted towards the landed channel and group. If it occurs after the call hang time has expired, it will be targeted towards the TX Call Member.
When using the Last Landed Channel option, it is recommended for each group to have its own configured channel. This way there is only one group associated with a channel, essentially making the Last Landed Channel and the Last Landed Group the same.
2.5.3.3 Scan Members with Similar Receive Parameters
When adding members to a scan list, it is important to be conscious of the differences and similarities between their receive parameters. A scan list that contains scan members with the same receive parameters but different transmit parameters may result in misdirected reply transmissions. This is best explained by first describing the simplest example of such a scenario.
F2
F1
F1
F2
Radio 1
Channel 1
Scanning
Radio
F3
F1
F1
F3
Radio 2
Channel 2
Figure 2-10 Misdirected Response while Scanning
In this example, a scan list contains two scan members, Channel 1 and Channel 2. Channel 1 is an analog channel configured for carrier squelch with a receive frequency of F1 and a transmit frequency of F2. Channel 2 is an analog channel configured for carrier squelch with a receive frequency of F1, but with a transmit frequency of F3. A scan list such as this implies that there is a repeater that is transmitting on F1 and receiving on F2, and another that is transmitting on F1 and
receiving on F3 (See Figure 2-10 “Misdirected Response while Scanning” ). Since the radio only
listens and qualifies using the receive parameters while scanning, the scanning radio could monitor a transmission from either repeater on either scan member. It does not know if it has actually landed on the correct channel or not. It only knows that the receive parameters have been qualified for the current channel being scanned. In other words, it does not know if the transmit parameters of the channel it has landed on matches the receive parameters of the radio that is has monitored. If the radio has landed on the wrong channel, when the radio user replies, the radio will transmit on the wrong frequency. The result will be a misdirected reply about half the time. This scenario can be avoided by making at least one of the receive parameters unique. In an analog
November, 2008
46 System Feature Overview system, this could be done with the use of PL or DPL. In a digital system, this can be done by using a unique color code or unique group per channel. This will allow the scanning radio to only
“land” on the channel where all receive parameters match and therefore properly direct the user’s reply.
Scanning
Radio
F2
F1
Channel 1
F1
F2
Radio 1
F1
Radio 2
Figure 2-11 Misdirected Response while Scanning
Similar problems can occur if one scan member has fewer qualifiers than the others. Taking the
example in Figure 2-10 “Misdirected Response while Scanning” again, Channel 1 is still an analog
channel configured for carrier squelch with a receive frequency of F1 and a transmit frequency of
F2. However, Channel 2 is now a digital channel configured for Color Code 1 and Group 10 with a receive frequency of F1 and a transmit frequency of F3. The receive parameters in this example are different, but Channel 1 has few qualifiers. Channel 1 is configured to land on any transmission that breaks squelch. This means that any transmission that occurs on Channel 2 will be heard on
Channel 1 as an analog signal. This scan list will not only result in misdirected replies, but it also results in a digital transmission being played out the speaker as analog. The net result is undesirable sounds presented through the user’s speaker. This type of configuration should be avoided at all times. This could be avoided by utilizing a PL or DPL on the analog channel instead of only carrier squelch.
November, 2008
System Feature Overview 47
Another similar problem occurs when the unique receive parameters between scan members are missing or cannot be determined. One scenario where this occurs is while scanning two slots of a repeater and a transmission is received directly from a subscriber on the same frequency. A radio in repeater mode can receive a transmission directly from a radio. However, in direct mode, slot numbering is not utilized. Therefore, if a radio is scanning two scan members with the same qualifiers with the exception of the unique slot number, when it receives a transmission without a slot number, either scan member will monitor it and “land”. When the user replies, the transmission will be returned through the repeater on whichever slot assigned to the scan member it was monitored on. Depending on the configuration of the direct mode radio and its proximity to the repeater, the transmission may or may not be monitored. This can be managed by having different groups configured for each slot. This ensures that each slot has unique identifiers besides just the slot number. However, this does not help if the subscriber in direct mode is out of range of the repeater. This is why it is not good practice to transmit in direct mode in the RF range of the repeater.
Generally, these scenarios can be avoided if scan lists are created with scan members that have unique receive parameters.
November, 2008
48 System Feature Overview
2.6 Site Roaming
MOTOTRBO supports the ability to automatically roam between sites of an IP Site Connect system.
The portable and mobile can be configured with a roam list that contains a list of channels, each of which is one site (one repeater) of an IP Site Connect system (wide area system). The radio searches through the list of sites and selects the one with the strongest signal, and identifies this site as its current home site. The radio remains on this home site until the signal strength has dropped below a programmable threshold or when it has lost communications with the home site, at which time it attempts to find a better home site. If a better home site is not found, it remains on the previous home site and continues searching. Note that roaming occurs while the user is not in a call. Roaming is not supported while the user is in a call.
Although site roaming functions automatically, the radio user can be provided the ability to control when and where the radio roams. The radio user can lock on to a particular site, or remain unlocked and allow the radio to choose the appropriate site. To manually change sites, the user can either change their radio dial position to the desired channel or site, or they can initiate the
Manual Site Roam feature and have the radio find the next available site. When the user changes radio dial positions, the radio always begins on the selected channel. The Site Lock On/Off and
Manual Site Roam controls can be configured to be accessible through a button or the menu.
The radio user is provided indications via the LED on when the radio is roaming. They are also provided an indication on which site the radio is currently on when the user enables Site Lock via button press.
The radio has two methods in which it accomplishes the act of roaming; a passive method and an active method.
2.6.1 Passive Site Searching
The Passive Site Search method has the radio searching through a list of sites and selecting the one with the strongest signal. This method is utilized whenever the site is unlocked. It relies on repeater transmissions in order for the subscriber to determine which site has the strongest signal strength. Since it is expected that the radio will encounter other activity while performing the
Passive Site Search, it qualifies the signal using the sites’ programmed color code prior to selecting it as the new home. In addition, it sorts the sites in the roam list according to their signal strength in order to optimize follow up roams. Sites that have been detected in previous roam attempts and are assumed to be near by are searched before those that have not been detected before. Also, while roaming, the radio inspects the current home site in between other sites in order to minimize the time away. This strategy provides priority to the last home site and minimizes missing any transmissions while performing the roam attempt.
While passively roaming, the radio temporarily leaves the current home channel and inspects other sites to decide if a better site is available. It is important to note that since the radio is temporarily away from the home channel, it is possible to miss the beginning of a transmission
(late entry). Because of this, it is not advisable or required to perform passive roaming all the time.
Therefore, the radio should only passively search for a better site when the current home site is no longer desirable. If the radio is within good coverage of a site, there is no need to search for a better site. In other words, the radio should only passively roam when the radio has moved far enough away from the site that its signal strength has degraded below an acceptable value or when its signal is no longer present. The signal strength threshold to initiate the Passive Site
November, 2008
System Feature Overview 49
Search (Roaming RSSI Threshold) is configurable via the CPS. See “Configuring the Roaming
RSSI Threshold” on page 53 for suggestions on setting the Roaming RSSI Threshold for various
site configurations and scenarios.
Initiating Passive Site Search and selecting sites based on signal strength works well when the repeater is transmitting, but the MOTOTRBO repeater does perform in a shared-use environment and is required to de-key when not in use. If there is no activity on a system, the Passive Site
Search cannot detect any repeaters and therefore is unable to determine at which site the radio should be on. Therefore, the repeater can be configured to transmit a beacon, which is a periodic short transmission when there is no interference, when not transmitting. Both the beacon duration and interval are programmable.
During times of no activity, the radio utilizes the signal strength of the beacon to determine when it should roam and which site it should roam to. If the radio does not receive a beacon in the expected duration, it assumes it is out of range of the repeater or that the repeater has failed and roams to another site. The duration of the beacon is a function of the number of sites in the IP Site
Connect system and therefore in the roam list. The interval of the beacon is a function of the shared use rules of the channel and how quickly a radio is required to roam when there is no
activity. See “Setting Beacon Duration and Beacon Interval” on page 58 for suggestions on setting
the beacon duration and interval for various site configurations and scenarios.
The radio does not perform Passive Site Search while:
• transmitting,
• receiving a call of interest,
• in emergency,
• in good RF coverage,
• in talkaround (direct) mode,
• radio disabled,
• received call alert,
• monitor mode,
• microphone is off hook,
• while in active menu, or
• while on a channel that has a scan list
2.6.2 Active Site Searching
The Active Site Search method consists of the radio sending a repeater wake-up message to each repeater in its sorted roam list until it finds an active site. This method is utilized when the user or radio initiates a transmission and the home site repeater cannot be awoken, or when the user initiates a Manual Site Roam.
In most cases, the Passive Site Search determines and selects the correct site if the radio is in the unlocked state. If the repeater’s beacon interval is set too long then it may be possible that the radio has roamed into a new site and has yet to receive a beacon. Note that the beacon interval is usually in the range of minutes and it typically takes more than a minute for a radio user to move out of range of one site and into the range of another. Until a new site is found, the radio considers the previous site as the home site.
November, 2008
50 System Feature Overview
If the user presses the PTT or a data transmission is requested at this time, the radio will first attempt to wake-up the home repeater. If the repeater does not wake up, the radio repeats this process for each roam list member. If the repeater does wake up, the radio synchronizes itself with the repeater, completes the transmission and make the new site the home site. If the end of the roam list is reached and a site is not found, the user receives a failure indication.
This entire process of discovering and synchronizing with an active repeater increases the voice access time of the transmission (time from PTT to Talk Permit Tone). However, this increase only occurs for one transmission since the next transmission proceeds regularly on the new site.
NOTE: Wake-up messages are always sent politely. This means that if the radio detects an interferring signal, the radio does not transmit a wakeup message on that roam list member. Instead, it continues performing an Active Site Search on the next roam list member.
If the user requests a Manual Site Roam, be it through a button press or menu item, the radio actively searches for the next available site using the process described above. The Manual Site
Roam does not necessarily find the best site, but rather allows the user to move to the next site that is in range and transmitting. If no site is found, a negative indication is provided to the user. If in direct mode, a successful site search changes the new channel found to repeater mode. An unsuccessful site search remains in direct mode.
NOTE: Generally, the radio does not perform any Passive Site Search during an emergency. No automatic roaming is performed when the radio is reverted during an emergency.
However, when configured to a non-revert emergency channel and with Active Site Search enabled, the radio will perform Active Site Search automatically whenever the RSSI of the repeater drops below the programmed threshold or if it no longer detects repeater
beacons. Note that Manual Site Roam is supported while in an emergency. See
“Emergency Revert, GPS Revert, and Roaming Interactions” on page 60 for more details.
It is important to note that Active Site Search causes wake-up messages to be transmitted on each roam list member’s frequencies until a site is found. This may not be agreeable in some areas where frequency overlap and sharing is common. In order to minimize the number of unwanted transmissions, the radio shall only transmit one polite wake-up message. If sending frequent GPS location updates while out of range, the radio shall limit the Active Site Search to only occur once every 30 seconds.
If this is still not acceptable in the area of operation, the radios should have automatic Active Site
Search disabled, the Manual Site Roam button removed, and the beacon interval should be configured as short as possible. This ensures that the Passive Site Search finds new sites quickly and the user has no method to initiate an Active Site Search. Note that if Active Site Search is disabled, there will be no roaming while in an emergency.
2.6.3 Roaming Considerations
2.6.3.1 Configuring a Roam List
When configuring a Roam List it is important to keep in mind that a system can contain more than one IP Site Connect system, or also known here as a wide area system. A wide area system is made up of one or two wide area channels. Each wide area channel is an individual voice path, in other words, the users on the same wide area channel monitors each other on any site.
November, 2008
System Feature Overview 51
Figure 2-12 shows a system with 2 sites, 2 wide area systems, each with 2 wide area channels.
Wide Area System 1, Channel 1 (WAS1 CH1) represents a wide area channel in wide area system
1.
Site 1
WAS1 CH1
WAS1 CH2
WAS2 CH1
WAS2 CH2 Network
Site 2
WAS1 CH1
WAS1 CH2
WAS2 CH1
WAS2 CH2
Figure 2-12 Two Wide-Area Systems, Each with Two Wide-Area Channels
Each wide area channel should have its own roam list. The roam list should contain one logical channel from each site that corresponds to the wide area channel. A logical channel is defined as the frequency pair, color code, timeslot combination. If there are multiple personalities (CPS
Channels) that reference the same logical channel, only one should be added to the wide area channel roam list. Only wide area channels should be added to the roam list.
The table below shows an example of the two site configuration in CPS. The colors match those of
Zone/
Folder
(Alias)
Zone 1
(Site 1)
Zone 2
(Site 2)
Personality
(CPS Channel)
# - Alias
1 – SITE 1 TGA
2 – SITE 1 TGB
3 – SITE 1 TGC
4 – SITE 1 TGD
5 – SITE 2 TGA
6 – SITE 2 TGB
7 – SITE 2 TGC
8 – SITE 2 TGD
4
4
3
3
2
2
1
1
Freq Pair
Logical Channel
Color
Code
2
2
2
2
1
1
1
1
Time Slot
1
2
1
2
1
2
1
2
Group
TGA
TGB
TGC
TGD
TGA
TGB
TGC
TGD
Roam List
# - Alias
1 – WAS1 CH1
2 – WAS1 CH2
3 – WAS2 CH1
4 – WAS2 CH2
1 – WAS1 CH1
2 – WAS1 CH2
3 – WAS2 CH1
4 – WAS2 CH2
November, 2008
52 System Feature Overview
The roam lists are configured as shown below:
Roam List
# - Alias
1 – WAS1 CH1
2 – WAS1 CH2
3 – WAS2 CH1
4 – WAS2 CH2
Personality (CPS Channel)
# - Alias
1 – SITE 1 TGA
5 – SITE 2 TGA
2 – SITE 1 TGB
6 – SITE 2 TGB
3 – SITE 1 TGC
7 – SITE 2 TGC
4 – SITE 1 TGD
8 – SITE 2 TGD
As can be seen there are 4 roam lists required for the 4 wide area channels. Each roam list contains only one personality that references the desired logical channel at each site. Although not necessary, personalities that correspond to a site can be placed together in their own zone (or folder). This will help further remove the concept of site from the radio user and allow the site roaming feature to choose the appropriate site. If they must manually choose a site, they can change zones. Using the actual name of the site as the zone alias will help clarify this to the end user, but it is not required. Since the same group is mapped to the same dial position in each zone, the user will have the same group selected as they change through the sites (zones). In this example the personalities are aliased with the group names, but other aliases that define Site,
Channel, or Group name can be used. If there are more than one group per wide area channel, a roam list can be created for each group to utilize.
It is important to understand that when the radio determines a new home site to be one of the roam list members, it will only utilize the logical channel attributes of the roam list member. The remaining attributes will be used from the selected personality.
The following logical channel attributes of the home site are utilized:
• Transmit Frequency and Transmit Reference Frequency,
• Receive Frequency and Receive Reference Frequency,
• Color Code,
• Time Slot,
• Talkaround Setting,
• GPS Revert Channel
• Emergency System (Including Emergency Revert Channel)
Take specific note of the GPS Revert and Emergency Revert channels. Because physical channels will be different per site, the revert channels must change when the radio roams to another site. It is recommended that emergency settings (other than revert channel) should be the same for all personalities within a roam list. Otherwise the radio may perform an emergency differently as it moves from one site to another.
The remaining personality attributes (Transmit and Receive Group List, Channel Access, etc.) will be used from the currently selected channel regardless of which site the radio is currently roamed to. It is good practice to make these parameters identical for personalities within a roam list so that
November, 2008
System Feature Overview 53 the radio acts the same regardless if it roams to the personality or if the user selects the personality.
2.6.3.2 Scan or Roam
When selecting a roam list for a personality to utilize, one will notice that a personality cannot contain a roam list and a scan list. MOTOTRBO does not currently support the ability to roam between sites and then scan channels at a particular site. Therefore while on a particular personality, a user has the ability to roam or scan, not both.
2.6.3.3 Configuring the Roaming RSSI Threshold
The Roaming RSSI Threshold is a CPS configurable parameter that controls the signal strength a subscriber needs to reach before searching for another site. If the RSSI measurement of the currently determined home site is above the specified Roaming RSSI Threshold, then the radio will remain on that site and not roam. Once the RSSI measurement drops below the threshold it will begin a Passive Site Search process to find a site with higher signal strength. This parameter essentially controls the distance away from a site a subscriber will begin looking for another site. In real life environments RF coverage is seldom a perfect circle, but to simplify this explanation, coverage will be abstracted as a circle.
It is important to note that while passively roaming the radio temporarily leaves the current home site to determine if a stronger site is available. Since the radio is temporarily away from the home channel, it is possible to miss the beginning of a transmission (i.e. enter the call late). Because of this, it is not advisable to perform passive roaming all the time.
The setting of the Roaming RSSI Threshold is a balance between when a radio will leave one site and look for the next versus how often the radio will perform roam and therefore increase the chances of late entry to voice calls. If the Roaming RSSI Threshold is to low, the radio will remain on a low signal strength home site even though there might be a stronger site available. If the
Roaming RSSI Threshold is too high, the radio will be roaming in full coverage of a repeater and
causing late entry when not required. Figure 2-13 shows the impact of the Roaming RSSI
Threshold value in relationship to the good coverage line (dotted) which most system coverage is
November, 2008
54 System Feature Overview designed to meet. Note that the Roaming RSSI Threshold is a negative number therefore a high value is -80dBm and a low value is -120dBm. The colored area is where the radio would roam.
Good Coverage
Low Roaming RSSI Threshold High Roaming RSSI Threshold
Not Roaming
Roaming
Figure 2-13 Roaming Triggered by Roaming RSSI Threshold Value
The default value of the Roaming RSSI Threshold is -108dBm. It can be programmed for anything between -80dBm and -120 dBm. A value of -108dBm is approximately 80% of the good coverage.
Therefore roaming will occur in the outer 20% of coverage. The default value is acceptable for most configurations but may not be optimal in a some particular configurations. Before setting the
Roaming RSSI Threshold, one must consider the customer’s site configuration.
Consider the following four basic site configurations:
1. Dense Overlapping Coverage (Urban) – This type of coverage consists of dense sites with generous overlap. This coverage type is often found in large cities or highly populated areas. Overlapping sites utilize different frequencies. Non-overlapping sites may share frequencies, but those that do share frequencies need to have different color codes if they need to be distinguished while roaming. This type of coverage is highly likely to encountered shared use on one or all of its sites. A radio user may be within coverage of three to four sites at a time. The time it takes a radio user to move from the coverage of one site to another is in the range of 10 minutes.
2. Isolated No Overlapping Coverage (Rural) – This type of coverage consists of isolated sites with little to no overlap. This coverage type is often used for isolated sites in rural areas, although could be used to cover a single part of a small city. Non-overlapping sites may share frequencies, but those that do share frequencies need to have different color codes if they need to be distinguished while roaming. This type of coverage is less likely to encountered shared use although possible. A radio user will only be within coverage of one site at any time. The time it takes a radio user to move from the coverage of one site to another is in the range of multiple hours.
November, 2008
System Feature Overview 55
3. Corridor Coverage – This type of coverage consists of in-series slightly overlapping sites.
This coverage type is often used for covering highways, train tracks, shore lines, or rivers.
Frequency re-use is common in this configuration since one site only overlaps with its two adjacent sites. Non-overlapping sites may share frequencies, but those that do share frequencies need to have different color codes if they need to be distinguished while roaming. A radio will only be within coverage of one to two sites at a time. The time it takes a radio user to move from the coverage of one site to another is in the range of an hour.
4. Multi-Floor Coverage – This type of coverage consists of dense extremely close sites with short range coverage and generous overlap. This coverage type is often used for covering tall buildings, or deep tunnels. Frequency re-use is not common due to the small coverage footprint usually implemented with in-building radiax antenna systems. This coverage type also often encounters quick signal strength drop offs due to the nature of in building coverage. Non-overlapping sites may share frequencies, but those that do share frequencies need to have different color codes if they need to be distinguished while roaming. A radio will only be within coverage of one to two sites at a time. The time it takes a radio user to move from the coverage of one site to another is in the range of one minute.
Reference the following diagrams.
TX = F1
RX = F2
CC = 1
TX = F3
RX = F4
CC = 2
TX = F5
RX = F6
CC = 4
Figure 2-14 Dense Overlapping Coverage (Urban)
TX = F1
RX = F2
CC = 3
November, 2008
56
TX = F1
RX = F2
CC = 1
TX = F5
RX = F6
CC = 4
TX = F1
RX = F2
CC = 3
Figure 2-15 Isolated No Overlapping Coverage (Rural)
TX = F1
RX = F2
CC = 1
TX = F3
RX = F4
CC = 2
TX = F1
RX = F2
CC = 3
TX = F5
RX = F6
CC = 4
Figure 2-16 Corridor Coverage
System Feature Overview
TX = F3
RX = F4
CC = 2
November, 2008
System Feature Overview 57
TX = F1
RX = F2
CC = 1
TX = F3
RX = F4
CC = 1
TX = F5
RX = F6
CC = 1
TX = F7
RX = F8
CC = 1
Figure 2-17 Multi-Floor Coverage
The site configuration should be taken under consideration when the Roaming RSSI Threshold is set. For example if the customer has a “Isolated No Overlapping Coverage” the threshold can be set to its lowest value of -120dBm. Because there is no overlap, there is no reason for the radio to start roaming until well outside of the coverage range of the repeater. For extremely close sites with large overlaps and quick signal drop off like the “Multi-Floor Coverage”, it might be better to set to it to a higher value so that the radios search for stronger sites closer to the repeater. The following table is the suggested setting for each basic site configuration. Many radio systems will have a combination of site configurations so the system designer will need to take all configurations into consideration and choose an appropriate value.
Site Configuration
Isolated No Overlapping Coverage (Rural)
Corridor Coverage
Dense Overlapping Coverage (Urban)
Multi-Floor Coverage
Recommended
Roaming RSSI Threshold
–120 dBm
–110 dBm
–108 dBm
–102 dBm
% of Outer Range
Radio Will Roam
Out of Range
10%
20%
50%
It is important to note that the preceding Roaming RSSI Thresholds assume the outbound and inbound RF coverage of the system is balanced. In other words, when a radio is within good outbound coverage of the repeater the radio’s inbound transmission can reach the repeater. Since the roaming algorithm uses the outbound transmission to determine when to roam, having an unbalanced system can cause radios not to roam even though they can no longer reach the repeater. This can lead to radio transmissions that do not reach the repeater and are therefore not repeated.
November, 2008
58 System Feature Overview
One method to rectify this problem is to lower the output power of the repeater. This decreases the outbound coverage area, but ensures that if a subscriber can hear the repeater well, it can respond successfully. If lowering the output power is not desirable, the Roaming RSSI Threshold needs to be raised higher (less negative) than the recommended values. This forces the radios to roam to another site within very good RF coverage of another. This value may be different for portables and mobiles since they have different output power and therefore different inbound coverage. Portables may need a higher (less negative) Roaming RSSI Threshold than mobiles.
Also note that there is one Roaming RSSI Threshold per roam list. This means that if one site has an inbound outbound imbalance and another does not, it may be difficult to find the correct
Roaming RSSI Threshold to exactly accommodate both sites. In other words if you set the threshold to roam correctly on the imbalanced site, it may end up roaming too early on a balanced site.
2.6.3.4 Setting Beacon Duration and Beacon Interval
If there is no activity on a system, the repeaters will hibernate and the radio’s Passive Site Search are not able to determine the signal strength, and therefore, which site is best since repeaters are not transmitting. Because of this, the repeater can be configured to transmit a beacon when not active and there is no other interfering signal. During times of no activity, the subscriber utilizes the signal strength of the beacon to determine when it should roam and which site it should roam to. If the subscriber does not receive a beacon in the expected duration, it assumes it is out of range of the repeater (or the repeater has failed) and attempts to roam to another site.
Both the beacon duration and the interval are programmable via CPS. The beacon duration is only configured in the repeater, but the beacon interval is programmed in both the repeater and the radio.
The duration and interval of the beacon is a function of the over-the-air shared use rules in the customer’s region. The beacon duration is dependant on the number of sites in the IP Site
Connect system and therefore in the roam list. The beacon interval is dependant on how quickly the radio is expected to roam to and from a site when there is no activity. The minimal duration and interval need to be met while keeping within the shared use guidelines of the region.
The ratio of the beacon duration and beacon interval equate to how often the repeaters transmit while there is no inbound radio activity, i.e. the beacon transmit ratio. This ratio is not directly programmed into the system, but is rather a guideline for setting the Beacon Duration and Interval.
If on a shared use frequency the beacon transmit ratio should be kept low. The target ratio is between 5% and 10%. In other words, if there is a need to increase the beacon duration, the beacon interval must also increase in order to keep the correct ratio.
If the beacon duration is configured too short it can be difficult for a roaming radio to detect it. This is especially true as the number of sites increases. As the amount of time between a roaming radio’s repeated roam attempts to a particular site increases, it is less likely to be inspecting the site at the exact moment that the beacon is transmitted. Recall that the home site is sampled inbetween other sites, which increases the overall cycle time. A user is typically within the coverage of no more than 4 sites at any given time, therefore even with a large roam list, most of the sites have no activity and can be inspected very quickly. If numerous sites have shared-use frequencies
(i.e. interference) the radio takes longer to get through its roam list and this increases the time between inspections of one particular site. Note that because the roam list is sorted by signal strength, the nearer sites are inspected first. Alternatively, if a user is transitioning to a site that they have not visited lately, the first roam may take slightly longer, but once it is has been detected this site moves to the front of the roam list. To improve the likelihood of receiving the beacon, the
November, 2008
System Feature Overview 59 beacon duration should be increased. It is safer to have a beacon duration longer than shorter, but keep in mind that if the duration is increased, the beacon interval must be increased to meet the beacon transmit ratio.
The beacon interval controls how quickly a radio can roam to a site and how quickly it roams away from a site when there is no activity. When roaming with no system activity, a radio needs to see a beacon in order to roam to a new site. If the repeater beacon is sent out every one minute, the radio may be one minute deep into the site before it sees the site and roams to it. Similarly, when roaming with no system activity, a radio may be one minute outside of the site before it attempts to roam. The impact of this value often changes based on how quickly the users are traveling. For example a car driving 60 m.p.h. can cover a mile a minute and therefore will be one mile into or out of a site before roaming. This could be acceptable for site configurations such as the “Isolated No
Overlapping Coverage” or the “Corridor Coverage”, but the “Dense Overlapping Coverage” coverage type may require a quicker beacon since it will both trigger the leaving and entering of sites. Note again that if the user initiates a transmission before the passive roam finds the beacon, the radio will attempt to wake-up the site repeater.
A one minute beacon interval may not be an issue for users on foot unless the sites are very close like in the “Multi-Floor Coverage” example. In this case a user in an elevator can move between sites at a very high rate. A one minute interval may cover the entire duration of an elevator ride from the first floor to the top. Here, it is recommended to keep the beacon interval in the range of
20 seconds. Note that a beacon transmit ratio of a 5% may not be achievable for systems with a high number of repeaters. In this case the designer may either decide to abandon the target beacon transmit ratio since in-building coverage usually does not propagate very far or have neighbors to interfere with, or lower the beacon duration to only cover the max number of overlapping sites a radio may ever see.
The table below is the recommended beacon duration and beacon interval (8% beacon transmit ratio) for a varying number of sites. The default value is a 4.32 second Beacon Duration with a 60 second Beacon Interval.
Number of Sites in
Wide Area System
10
11
12
7
8
9
13
4
5
6
2
3
Beacon Duration
(sec.)
6.72
7.92
9.12
10.32
11.52
12.72
13.92
0.72
1.92
3.12
4.32*
5.52
Beacon Interval
(sec.)
90
100
120
130
150
160
180
10
30
40
60*
70
November, 2008
60 System Feature Overview
Number of Sites in
Wide Area System
14
15
Beacon Duration
(sec.)
15.12
16.32
Beacon Interval
(sec.)
190
210
* Default Values
If shared use is not a problem in the customer’s region, the beacon transmit ratio become less important and it may be desirable to increase the beacon duration and decrease the beacon interval past what is identified here. If the automatic Active Site Search feature is going to be disabled, it is advisable to lower the beacon interval as much as possible since radios will rely only on it to find the appropriate site.
2.6.3.5 Emergency Revert, GPS Revert, and Roaming Interactions
Emergency Revert and GPS Revert are specific to the current home site. This is important since the revert channel of one site will most likely not be the revert channel of another site. Although it is possible to revert while roaming, roaming while reverted is limited.
While in emergency and configured as non-revert the radio will not perform Passive Site Search. If
Active Site Search is enabled, the radio performs an automatic Active Site Search when the RSSI of the repeater drops below the programmed threshold or if it no longer monitors the repeater beacons (normal triggers for passive roam). This is considered as a more aggressive method to site search as compared to passively searching. The radio also supports the ability to trigger an automatic Active Site Search on transmit request by the user or automatically by the radio (GPS).
Standard Manual Site Roam is also supported. Active Site Search can be enabled or disabled via the CPS.
While reverted due to emergency, no automatic roaming occurs. This is primarily due to the fact that the emergency revert channels may not be on the same logical channel, and the emergency handlers may not be the same. It is not desireable for a user to automatically leave one emergency handler and switch to another without notification.
A radio will perform an Active Site Search (using the selected personality’s roam list) when the emergency is first initiated if the revert channel is not available. Once on the revert channel, only
Manual Site Roam is available. In other words, if a user enters emergency, and then roams out of range of the revert channel, the radio does not automatically roam even if the user presses the
PTT. When a Manual Site Roam is initiated while reverted, the radio performs an Active Site
Search using the selected personality’s roam list.
When a new site is found due to a roam while in emergency, the emergency process restarts on the new site (similar to manually changing the dial position) if the new home is provisioned for revert. If the new home is not provisioned as revert, the emergency process does not restart since the radio never left the wide area channel. It is assumed that the original target of the emergency is still monitoring since the source never left the wide area channel. The radio also assumes that emergency handling configuration (outside of revert) is the same across the wide area channel.
The radio reverts if the new home site is provisioned as such. If a new site is not found, the radio returns and remains on the original site or the site revert channel, if provisioned. Per normal revert rules, upon clearing the emergency the radio would return to the home site. If the radio roams to a site that has Emergency Disabled (or no Emergency System) then radio remains in emergency but
November, 2008
System Feature Overview 61 does not process the emergency sequence. The user can then attempt another Manual Site Roam to find a site that does have emergency.
Note that in most cases, the passive search while not in emergency should get the radio on the correct site and therefore when it emergency reverts, it should still be at the same site. If in Silent
Emergency mode, no ergonomics associated with Manual Site Roam are displayed.
While GPS reverted, no automatic roaming is supported. If the GPS revert channel is out of range, the data message is dropped. On return to the home channel after a failed GPS revert, the radio will initiate an Active Site Search using the selected personality’s roam list. This will make sure that an available site is found prior to the next GPS revert attempt.
While in emergency (initiator, not receiver) and GPS revert occurs, no automatic roaming is supported while reverted. If GPS revert channel is out of range, the data message will be dropped.
On return to an emergency revert channel, after a failed GPS revert, the radio will NOT initiate an
Active Site Search since this is not supported while in emergency.
See “Emergency Revert and GPS Revert Considerations” on page 194 for further details on how
Emergency Revert and GPS Revert operate together.
In summary:
Feature
Passive Site
Search
Automatic Active Site
Search on TX Request
Tactical Emergency
(Non-Revert)
Not Available Available
Emergency Revert
GPS Revert
Not Available
Not Available while Reverted
Only Available on
Emergency Initiation
Performed After Dropping the Data Message
Automatic Active Site
Search on Loss of Site
Available
Not Available
Not Available
Manual
Site Roam
Available
Available
Available
2.6.3.6 Performance while Roaming
It is important to note that roaming (not just enabled, but in the act of searching) may cause some minor degradations in performance. Therefore, it is important that the Roaming RSSI Threshold and the radio’s Site Lock be set appropriately when not mobile. These degradations are similar to what a scanning radio would experience. Degradation may be experienced in the following areas:
• Late Entry to Voice Transmissions (Voice Truncation)
• Longer Preambles required for Control Messages and Data
• Increased setup time for Confirmed Private Calls
• Group Call Time to Talk Permit may increase if Site Search Required
While roaming the radio temporarily leaves the current home channel and inspects other sites to decide if a better site is available (similar to scan). This means that radio may not be present on the home site when a call starts. The home site is inspected between every other site to minimize the time away. This is similar to the scan ordering of a priority scan member.
November, 2008
62 System Feature Overview
One issue that arises from this situation is that if a group call or unconfirmed individual call starts while the target is inspecting another site, the may be a short delay before joining the call. This will equate to voice truncation for the target radio.
Another issue faced will be the need for longer preambles in order for command and control messages, and data to be received by a radio that is currently roaming. Without an extended preamble, roaming radios will miss the message.
The need for preambles also affects the setup time for confirmed private calls. Confirmed private calls utilize command and control messaging to setup the call. In addition, the first setup attempt does not utilize any preambles. This increases the setup time between radios that are not roaming.
This means that the first setup attempt of a private call is not successful if the target radio is roaming. The radio then attempts a second time with a preamble. This second attempt will more likely be successful and the private call will continue.
If the current home site cannot be awoken, the radio attempts to locate another site using an automatic Active Site Search. As the radio attempts to wake-up other sites, the user must wait.
This increase in time will be recognized as an increase in the time from PTT to receiving the Talk
Permit Tone. This is not expected to occur often if the beacon interval is set appropriately.
It is expected that the value that the roaming feature adds is worth these performance degradations. The Beacon Interval and the Roaming RSSI Threshold should be set appropriately to minimize the amount of time a radio is searching for a site.
2.7 Voice and Data Privacy
Over a digital channel, MOTOTRBO supports a way to keep communication (both voice and data) private. Privacy protects the information, where “protection” means that the MOTOTRBO resists reading of data payload or listening of voice by anybody other than the intended receivers.
MOTOTRBO does not provide any mechanism to authenticate the radios or radio users and it does not protect the integrity of the messages.
2.7.1 Types of Privacy
MOTOTRBO offers two type of privacy mechanisms - Basic and Enhanced. Both of them utilize
Motorola proprietary mechanisms/algorithms and therefore are not interoperable with other vendor’s privacy offerings.
The main differences between Basic and Enhanced Privacy are that the Enhanced Privacy provides higher level of protection and it supports multiple keys in a radio compared to one key in the case of Basic Privacy.
The two privacy mechanisms are not interoperable. Both mechanisms cannot operate in a radio at the same time. This implies that either all the digital private channels support Basic Privacy or all the digital private channels support Enhanced Privacy. Also all the radios on a repeater must use the same privacy mode even if they are in different groups. In direct mode, all the radios that communicate with each other must use the same privacy mode.
The software for both co-exists in a radio and repeater. While configuring a radio or repeater using
CPS, the CPS user selects the radio-wide privacy type to be either Basic or Enhanced.
November, 2008
System Feature Overview 63
2.7.2 Strength of the Protection Mechanism
Both Basic and Enhanced Privacy do not provide resistance against “replay attack” (i.e. an adversary intercepts the data and retransmits it) or “traffic analysis” (i.e. disclosure of information that can be inferred from observing the traffic patterns).
Their protection mechanism requires a key that is shared only among the intended parties. They do not use any hardware-based cryptographic engine or a hardware-protected memory for storage of keys.
The resistance provided by the Basic Privacy is minimal due to the following reasons:
• The Basic Privacy uses a non-cryptographic algorithm to transform plain voice/data into protected voice/data. It is possible for an adversary to obtain the key by storing a few overthe-air voice or data packets and performing few simple mathematical operations.
• The Basic Privacy uses 16 bit keys. A user selects a key from 255 predefined keys stored in the CPS. The limited number of possible keys makes it easy for an adversary to guess the key in-use.
The intended use of the Basic Privacy is to stop casual eavesdropping only.
The resistance provided by the Enhanced Privacy is significantly better than the resistance provided by the Basic Privacy due to the following reasons:
• The Enhanced Privacy uses a cryptographic algorithm to transform plain voice/data into protected voice/data. The algorithm is the well-known ARC4. (Alleged RC4) and is same as
RC4 1 . A cryptographic algorithm makes it very difficult for an adversary to obtain the key from over-the-air protected messages.
• The Enhanced Privacy uses 40 bit long keys. A radio can store up to 16 keys and the
Enhanced Privacy allows using different keys for different channels. The large number of possible keys (approximately 1 trillion) makes it difficult for an adversary to guess the value of a key. Note that 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.
2.7.3 Scope of Protection
Both Basic and Enhanced Privacy protect 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 and the embedded and standalone digital signaling are also not protected.
The protection is provided in all the operational modes (direct mode, repeater mode, and IP Site
Connect) and through all the communication paths between the sending radio and the destination radio. This implies that the voice and data messages remain protected in the following situations:
1.
The name "RC4" is trademarked by RSA Security. Although "unofficial" implementations are legal, but the RC4 name cannot be used.
November, 2008
64 System Feature Overview
• Over-the-air, in direct mode;
• Over-the-air and inside a repeater, in repeater mode; and
• Over-the-air, inside repeaters, and over the back-end network, in IP Site Connect.
Note that the Basic and Enhanced Privacy does not protect the voice and data messages between a radio and its option board or between a radio and its accessory (including a MDT). Any data that extends past the radio network is not protected. For example, text messages from field units to text message dispatchers or e-mail addresses on a network are not protected once they leave the destination radio (i.e. a Control Station).
Both Basic and Enhanced Privacy protect Individual voice call, Group voice call, All system call,
Emergency call, and all Packet data calls (i.e. Individual, Group, unconfirmed, and confirmed).
November, 2008
System Feature Overview 65
2.7.4 Effects on Performance
Basic Privacy uses only one key, which is known to both the sender and the receiver. This eliminates the need to transport crypto parameters (e.g. Key Identifier) with the voice or data payload. A voice message, in case of Basic Privacy, neither requires any modification in the payload nor any additional headers. Therefore, the System Access Time and the audio quality of a
Basic privacy protected voice is same as that of an unprotected voice.
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 (e.g. key Identifier, Initialization Vector) with the voice or data payload. A voice message, in the case of Enhanced Privacy, 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 except when Talk Permit Tone is enabled (in repeater mode) where the additional header replaces one of the normal voice headers. The replacement of payload bits reduces the voice quality. Note that the reduction in voice quality is barely noticeable.
In case of both Basic and Enhanced Privacy, a data message requires an additional header to distinguish between an unprotected data message and a protected data message. In case of
Enhanced Privacy, the additional header is also used to transport crypto parameter. 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).
2.7.5 User Control Over Privacy
The Customer Programming Software (CPS) allows a System Installer to select the type of privacy
(i.e. Basic and Enhanced Privacy). CPS also allows the enabling or disabling of the privacy service of a channel. The option to toggle the privacy capability per channel can additionally be given to the radio user by providing a menu entry or programmable button. Without the menu entry or programmable button, the radio user is essentially “locked” to the channel’s privacy setting. It is important to note that a user can set or reset privacy for a channel, and not for the radio. If the user is provided with the menu entry or programmable button, and he toggles the privacy setting, only the selected channel’s privacy setting is toggled and remains toggled even after the user changes channels or zones. Toggling the privacy setting on a channel will not affect the privacy setting on other channels.
The privacy setting of a channel controls the transmit privacy setting, not the receive privacy setting. A radio on a privacy-enabled channel always transmits protected, while a radio on a privacy-disabled channel always transmits unprotected. However, the radio receives both unprotected and protected regardless of the channel’s privacy setting. Any time the radio receives a protected message, regardless of the channel’s privacy setting, the radio always tries to unscramble or decrypt the message. If a radio is never required to receive protected messages then it should be provisioned with a key that is different than the key(s) used by the rest of the system. Simply setting a channel to be privacy-disabled does not stop the radio from receiving protected messages. A radio receives a protected message correctly as long as it has the right key.
Therefore, when one radio user on a privacy-enabled channel transmits, every radio, regardless of its channel’s privacy-enabled or privacy-disabled status, will hear the transmission clearly if their provisioned Privacy Key is identical to that of the transmitting radio. A radio user receiving a
November, 2008
66 System Feature Overview protected transmission sees the green LED blinking rapidly. The receiving radio user should consider changing the privacy setting to match that of the call initiator when replying.
In case of Basic Privacy, a system utilizes only one key and if all radios are privacy capable, it is recommended that all radios are set to privacy enabled and equipped without the option to toggle the privacy settings by a radio user. Since Basic Privacy does not cause any degradation in audio quality, or decrease in performance, there is no reason for the normal user to switch between nonprivacy and privacy. Removing the option to toggle the setting from the radio user will safeguard against any complicated privacy mismatch scenarios.
2.7.6 Privacy Indications to User
It is important for a radio user to know the privacy status (i.e. enabled or disabled) of the current channel, and also to know if the received voice transmission is unprotected or a protected voice transmission. There is no privacy indication for incoming protected data transmissions.
Prior to transmitting, a radio user should check the privacy setting of the current channel. On privacy-enabled channels, an icon is shown on the front panel display of the radio when the radio is idle.
Table 7.1 Privacy-Enabled Channel Icon
Privacy Enabled Privacy Disabled no icon
Upon receiving a voice transmission, the radio user can know the privacy status of the voice transmission by observing the blinking rate of the receive LED. When receiving a protected voice transmission, the LED blinks green but at a quicker rate than when receiving an unprotected voice transmission.
If radio users in a call have mismatching privacy settings, but the same key, they are able to communicate, but the transmissions are protected in only one direction. In other words, only the transmissions from radios with privacy enabled are protected.
The radio does not automatically negotiate privacy settings, or block transmissions that are not protected. Therefore, it is up to the radio users to monitor the privacy indications to determine if all the users in the call have a matched privacy setting. The radio will display the privacy setting of the received transmission, but will blink if it does not match the transmit mode of the receiving radio.
When a privacy setting mismatch occurs, they should request the other members of the call to switch their privacy settings to match. The radio allows users to enable or disable privacy on the channel while on a call.
Radio users with non-display or numeric display radio models are not able to view the icon that is shown on a privacy-enabled channel. Therefore, it is recommended that such users should not have the option to toggle the privacy setting.
If non-display or numeric display radio users must be able to toggle between protected and unprotected, it is recommended that this be done by programming duplicate channels, one with
November, 2008
System Feature Overview 67 privacy enabled and one without, and the user should use the dial position to toggle between protected channels and unprotected channels. For example, dial position one may be set to communicate with a Group in unprotected mode, and dial position two may be set to communicate with the same group but in protected mode.
2.7.7 Key Mismatch
In case of Basic Privacy, a receiving radio assumes that the received protected transmission is protected using the same Key that it has, because the key identifier is not sent with the message.
If the receiving radio does not have the same key as the transmitting radio, the receiving radio cannot unprotect the transmission correctly. For voice transmissions, this results in unintelligible audio (sometimes referred to as digital warbles) being played through the target’s speaker. For data transmissions, this results in an unsuccessful data message transmission. This is because the IP/UDP headers of a data message when unprotected using a wrong key fail to CRC check.
On failure of the checksum, the data message is not delivered to the application.
In case of Enhanced Privacy, the key identifier is sent with the message and if the receiving radio does not have the key then it either remains muted (in case of voice message) or discards the data message. If the key value associated with the key identifier is different in the sender and receiver, due to a miss-configuration, then the voice transmissions will result in unintelligible audio and the data transmissions will be unsuccessful.
2.7.8 Keys and Key Management
In case of Basic Privacy, a radio is capable of holding only one Privacy Key. The same key is used to protect and unprotect voice and data transmissions over all the channels and for all call types:
Group Call, Private Call, All Call, or Emergency Call.
In case of Enhanced Privacy, a radio is capable of holding up to sixteen Privacy Keys, where keys are associated with channels. The relationship between keys and channels is 1:0...n. (in other words 1 to 0 or 1 to many) “0” means that keys may be provisioned into the radio but are not associated with any channel. In this case, the keys are used to unprotect a received message but are not used by the radio to protect a transmission.
A Privacy Key is provisioned in a radio using a CPS. The keys are not readable, editable, or erasable by the radio user. Once a key has been chosen and programmed into a radio, the key cannot be extracted and viewed by CPS. It can only be retained or overwritten.
In case of Basic Privacy, a CPS user can select one of the 255 prescribed keys. These keys are referenced by a key index from 1 to 255. Each key index references a particular 16-bit key that is used for protecting over the air. There is no option for a “blank”, “null”, or “zero” key. In case of
Enhanced Privacy, the valid range for the value of a Key is 1 to 1,099,511,627,774 (i.e.
FFFFFFFFFE in hex). The Key values 0 and 1,099,511,627,775 (i.e. FFFFFFFFFF in hex) are reserved and should not be used.
MOTOTRBO does not support remote or over-the-air programming of keys into a radio. Keys can be programmed in a radio using only CPS. CPS supports loading of the value and identifier of a
Key into a radio either manually or from a protected archive file (in case of Enhanced Privacy only). In case of getting the keys from a protected archive file, the CPS User selects the protected file and provides the password. The file is unreadable without a password. The CPS is capable of copying key(s) from one radio's archive into another radio's archive without the user needing to retype the key for each radio.
November, 2008
68 System Feature Overview
A customer may need to change one or more keys (in the case of Enhanced Privacy) with a set of new keys into a set of radios. Some of the reasons for changing keys are:
• Compromise of keys
• Security policy of the customer requires periodic update of keys
• Loss of a radio resulting in a concern that this may lead to compromise of keys or eavesdropping.
The easiest way to implement a key switchover is to gather all radios and re-program them at one go. But it may not always be possible to gather all the radios without seriously affecting day-to-day operations.
An alternate method is to create two zones where one zone is set to unprotected while the other is set to “protected”. The key can be changed on the protected zone and the users shall use the unprotected zone until all radios have been updated. Once all radios have been updated, the dispatcher informs the fielded radios to switch zones. This allows users to communicate in clear until the all radios are provisioned, and then all the users switch keys at the same time.
A similar zone strategy can be used to perform periodic key set changeovers. For example, when one zone has January’s keys and another duplicate zone has February’s keys. On the first of
February, the users switch to the February zone. Throughout February, the January zone is updated with March’s keys and renamed to “March Keys”. On the first of March, the users switch, and so cycle starts again. This makes sure that only two months of keys are compromised if a radio is stolen or lost.
2.7.9 Multiple Keys in a Basic Privacy System
Although a radio can only use one key in a Basic privacy system at a time, a Basic privacy system may utilize multiple keys to sub-divide a group into a set of groups. Note that this is not a recommended configuration, and some considerations need to taken into account, if the decision is made to utilize multiple keys in a system.
It is not recommended that Groups be sub-divided into smaller groups with the use of keys. This results in one sub-group of users hearing unintelligible audio (or digital warbles) when the other sub-group communicates. It is recommended that the users should be divided into Groups, and provisioned so that a user can not transmit nor receive on the other’s Group. If users with different keys are allowed to communicate with Basic privacy enabled, for example via a protected private call, a key mismatch will occur and unintelligible audio will be heard. Although these users with different keys will never be able to communicate privately, they will be able to communicate when privacy is disabled.
For example, two different Groups are isolated by provisioning different privacy keys. When a user in each Group needs to communicate to each other via a private call, they must do it with privacy disabled. If a radio user needs to communicate with both Groups via an All Call, the radio user must transmit in clear mode so that both Groups can monitor. If users respond with privacy- enabled, the user who initiated the All Call only monitors the responses protected with a matching key.
If the system is utilizing data applications and must communicate through a control station to the application server, all radios on a slot must have the same key or they will not all be able to properly communicate with the control station. For similar reasons, it is not recommended to have radios without privacy capability, i.e. older software versions, in the same Group as radios with
November, 2008
System Feature Overview 69 privacy capability. Since older radios are not provisioned with a Privacy Key, the audio will be muted. If radios with privacy capability need to communicate to radios without privacy capability, they will need to disable privacy before transmitting.
As a general rule, it is always recommended that groups with different privacy capabilities and settings be placed in different Groups and on different slots.
2.7.10 Data Gateway Privacy Settings
The privacy setting of a control station acting as the data gateway to the application server is very important for consistent data communications. This may even drive the privacy configuration of the rest of the system.
If a system contains some privacy-capable radios and some privacy-incapable (i.e. older software versions) radios then the control station must be privacy capable, but configured to transmit unprotected. This way, outbound messages can be received and processed by the older radios
(not privacy capable). Note that the privacy capable radios send their data protected and the control station will be able to decode these messages, as long as it has the proper key.
In case of Basic Privacy, there can only be one key per channel (or slot). Since the control station can only contain one key, it cannot communicate privately to two different Groups utilizing different keys. If a Basic Privacy system utilizes multiple keys, those users must be divided onto two separate channels (or slots), each with their own control station utilizing the proper key. Setting the control station to privacy disabled will not solve this problem since incoming messages such as
GPS or text messages may be protected using different keys and only one key can be used at the control station to unprotect. Therefore, although outbound messages would be functional, inbound messages would not be.
If users have the ability to toggle their privacy settings, it is acceptable to have the control station set to either privacy enabled or privacy disabled, but only if their provisioned keys match. If the control station is set to privacy enabled, and the radio is set to privacy disabled, one direction of the data communication will be protected and the other will be unprotected. Since radios set to privacy disabled will receive protected, and radios set to privacy enabled will receive unprotected, the communication path will work. If important data is being transferred to and from the fixed infrastructure, it is recommended that the control station should be set to “protected”. This will guarantee that at least half of the data transmission will be private. Also, the system will be tolerant if fielded radios are set to privacy disabled.
It is recommended that all radios including control station should have same privacy settings. If the privacy setting is enhanced privacy then the control station should have the transmit keys of all the radios and all the radios should have the transmit key of the control station.
2.7.11 Protecting One Group’s Message from Another
There may be a need for one Group’s voice and data to be protected against another over the same channel (same frequency and same slot). There may be some radio users who are members of one or more of the groups. In this case, if a group not only wants to protect their communication from intruders but also from other groups then each group should use separate keys for protection.
The System Installer should make each group that need to be protected as “TX Group” for a personality. The relationship between a personality and a group is 1:1. The System Installer should
November, 2008
70 System Feature Overview associate a key to a personality. The relationship between a key and a personality is 1:1. And therefore the relationship between a key and a group becomes 1:1. If a radio ‘X’ wants to make a protected private call to a radio ‘Y’ and if both the radios are member of a group ‘T’ then the radio
‘X’ goes to a personality whose “TX Group” is ‘T’. If there is no group where both the radios are member then it is not possible to send a protected message.
For a protected “All Call”, the transmitting radio should go to a specific personality and the key associated with that personality is present in all the radios. For a protected private call, the transmitting radio should go to a specific personality and the key associated with that personality is present in the receiving radio.
2.7.12 Updating from Basic Privacy to Enhanced Privacy
It may not be possible for a System Installer to update all the radios from Basic Privacy to
Enhanced Privacy in one session. In such cases, the System Installer instructs all the radio users to disable the Privacy feature and operate in clear mode. When instructed, the radio users disable the Privacy feature using the radio front panel. All the messages are transmitted in clear.
The System Installer updates the software of radios and configures the radios for Enhanced
Privacy. Once all the radios are upgraded, the System Installer updates the software of repeaters and configures them for Enhanced Privacy. The control stations acting as the data gateway should also be upgraded.
The System Installer instructs all the radio users to enable the Privacy feature. The radio users enable the Privacy feature using the radio front panel. The control stations also enable privacy. All the messages are transmitted using Enhanced Privacy.
November, 2008
System Feature Overview 71
2.8 Repeater Diagnostics and Control (RDAC)
Repeater Diagnostics and Control (RDAC) allows a system administrator the ability to monitor and control repeaters within the system. The following services are provided:
1. Repeater Diagnostics
• Read Enabled/Disabled Status
• Read Analog/Digital Status
• Read Wide or Local Area Status
• Read Transmit Power (High or Low) Status
• Read Available Channels (including Currently Selected)
• Read Inbound RSSI
• Read IPv4 Address and UDP Port (required for connectivity)
2. Repeater Alarm Reporting
• Detect and Report Receiver Lock Detect Failure
• Detect and Report Transmitter Lock Detect Failure
• Detect and Report Overheating
• Detect and Report AC Power Supply Failure
• Detect and Report Main Fan Failure
3. Repeater Control
• Change Enabled or Disabled Status
• Change Channels
• Change Transmit Power Level (High or Low)
• Reset Repeater
• Knockdown Repeater
The RDAC application can be configured to work over the network via IP or locally via USB.
When working over the IP network, the application communicates with all repeaters within an IP
Site Connect system using the same link establishment process that the repeaters utilize.
Therefore, it benefits from the existing link establishment and authentication utilized between repeaters. Note that the RDAC application can only communicate with one IP Site Connect system at a time. All services in the list above are available through the RDAC application.
When working locally, the RDAC application connects to a single repeater via USB. All services in the list above are available through the RDAC application.
The user also has access to the repeaters external GPIO pins. External equipment (or existing remote adapters and desksets) can be configured to set or read the GPIO pins to allow access to the repeater control services as well as access to indications that a minor or major alarm has occurred. The access to these GPIO pins further allows the radio installer to utilize the alarm pin and enable/disable pin to create a redundant switch over configuration. Alarm Reporting and
Control is available using the GPIO pins.
Note that any combination of RDAC connected over the Network, RDAC connected via USB, or connections via GPIO are supported.
November, 2008
72 System Feature Overview
The ability to change the repeater channel can be utilized to toggle channel parameters between predetermined settings. For example, if the repeater contains one channel that is in analog mode and another channel that is in digital mode, changing the channel between these channels essentially changes the mode from analog to digital. The same strategy can be used to toggle the wide area and local setting of a timeslot. One personality could be provisioned for two wide area channels, while the next has one wide and one local channel. Other channel parameters can be changed using the same strategy.
It is important to note that many control operations require the repeater to perform a reset before processing the control operation. During the reset the repeater will not be able to service inbound transmissions from fielded radios. Also note that the repeater takes no consideration to the ongoing traffic when instructed to perform a control operation. In other words if a call is in progress
(group call, individual call, all call, emergency call, data call, etc.) the repeaters perform the control operation and drop the call in progress. In addition, the IP connection between the repeater and the RDAC will be temporarily severed while the repeater is rebooting. The connection must be reestablished before additional operations can be performed. This should be taken into consideration before performing any control functions on an active repeater.
In addition to the repeater reporting alarms to RDAC application and setting the GPIO alarm pins accordingly, it is important to note that it also takes action when major alarms are received. The repeater will perform a reset after a major alarm is reported as an attempt to clear the alarm. If the alarm is not clear after reset it will reset again. This will continue until the alarm is cleared or the repeater is locked (3 major alarms). Once 3 major alarms have been reported, the repeater will enter the Locked state and set the Major Alarm Pin. At this time all the LEDs on the Repeater front panel will be solid. While in the locked state, the repeater will not service any calls over the air. The
RDAC application will display the locked state and have the ability to retrieve logs.
In order to exit the locked state, the repeater must be read and written to with the CPS to reset the major alarm counter. This is automatically done when CPS writes a codeplug to the repeater. Note that 3 major alarms almost certainly means that there is a hardware problem that should be addressed prior to clearing the locked state.
Alarms are categorized as shown below:
• Major Alarms - Receiver and Transmit Lock Detect Failure
• Minor Alarms - •Overheating, AC Power Supply Failure, Main Fan Failure
2.8.1 Connecting Remotely via the Network
Connecting RDAC via the network allows access to all repeaters in an IP Site Connect system. If a system has more than one wide area system (i.e. more than one Master Repeater) then more than one RDAC application is required to monitor all repeaters at the same time. The RDAC application is only required to know the static IP address and UDP port of the Master repeater. It will learn the addresses of the other repeaters through the Master. Similar to repeater communication, the
RDAC application should not require any specific firewall configuration. It will require the appropriate authentication be entered that is being utilized by the repeaters in the IP Site Connect system.
Although the network connection is designed for “connecting remotely”, a local network connection in close proximity to the repeater is supported.
November, 2008
System Feature Overview 73
The RDAC-IP application can communicate with enabled and disabled repeaters, knockdowned repeaters, digital and analog repeaters, and wide and local area repeaters. As long as they are on the network and communicating with the same Master repeater that the RDAC application is communicating with, they will be controllable via the application.
It is important to note that over-use (or misuse) of RDAC diagnostics could cause strain to the network link and therefore, cause voice degradation. For example, numerous requests for status or error logs could cause excess traffic on a network link which could delay voice through the network. Please review the network bandwidth considerations in later chapters.
2.8.2 Connecting Locally via the USB
Connecting RDAC locally via the USB provides the user with all the services of RDAC but only allows access to the local repeater. This connection is very useful if the repeater is in close proximity to the dispatch center or while performing service or trouble shooting locally.
2.8.3 Connecting Locally via GPIO Lines
Connecting locally via GPIO lines only allows access to the local repeater. The user has access to the repeater control services as well as access to indications that a minor or major alarm has occurred from the GPIO lines. The GPIO lines can be configured in various ways and can be integrated to communicate with a variety of external equipment.
A custom cable is needed to connect the repeater accessory port to the outside control device.
Below is an example of one configuration. Note that the pin out of the cable is dependent on how the GPIO lines are provisioned via CPS.
Repeater
GPIO Pins
GPIO Connections
Remote Adapter
Custom Cable
Desk Set
Standard Cable
Figure 2-18
November, 2008
74 System Feature Overview
2.8.3.1 RDAC Local Settings Rear Accessory Port CPS Programmable
Pins
The CPS offers a few repeater-wide settings as well as the ability to program the input and output pins on the rear accessory connector to meet the needs of the external equipment. Note that the repeater now supports up to 16 channels. This has made the signal mode setting in the previous releases obsolete.
The rear accessory also has some pins that can be programmed to specific input/output functions.
These pins can be programmed to either active high or low. See the table below for descriptions of these functions available for each GPIO pin.
CPS Programmable Pins
Major Alarm (Locked State)
Minor Alarm
Repeater Disable
Tx Power Level High
Repeater Knockdown
Channel Change
Description
This output pin is used to report a major alarm has happened 3 times, been reset three times, and the repeater is in now locked state.
This output pin is used to report minor alarm(s) is happening on the repeater.
Asserting this input pin triggers the repeater to enter disabled state. In this state, the repeater can not execute repeat functions.
Releasing this input pin will revert the repeater back to enabled state where the repeaters can start repeating calls.
Asserting this input pin triggers the repeater to change the TX power level to be high.
Releasing this input pin will revert the repeater back to TX low level low.
Asserting this input pin triggers the repeater to temporarily enter Repeat
Path Disable Mode. In this mode, the repeater’s transmitter will only be enabled by the external PTT and the audio source will be the Tx Audio
Input pin.
Releasing this input pin will revert the repeater back to Normal Mode where the repeaters transmitter can be activated by a qualified RF signal on the receive frequency.
*Note that repeater knockdown is not supported in digital mode.
There are up to 4 pins that can be configured and used for channel change.
The repeater can support up to 16 channels.
Asserting this input pin represents 1.
Releasing this input pin represents 0.
0000 represents first channel, 1111 represent the last channel.
November, 2008
System Feature Overview 75
2.8.4 Redundant Repeater Setup
By using the alarm feature and control feature together, it is possible to setup redundant repeaters.
So that when one repeater fails, the standby repeater can take over the repeat function.
Before installation, both repeaters are programmed with the same channel information. The installer configures one repeater as primary repeater and the other one as standby repeater. For the primary repeater, the installer configures one GPIO pin for major alarm reporting and configures the pin’s polarity. For the standby repeater, the installer configures one of its GPIO pins as repeater disabled control input pin and its polarity opposite of the primary repeater’s alarm pin polarity. When the primary repeater’s alarm pin becomes active it deactivates the disabled pin and the standby repeater becomes enabled. The antenna system is connected to the primary repeater and also connected to an antenna switch. The antenna switch is external to the repeater hardware. The installer connects the primary repeater’s alarm pin (output pin) and standby repeater’s repeater disable pin (input pin) and the antenna switch all together. The installer powers on the primary repeater first and verifies it is working with no major alarm reported. Then the installer powers on the standby repeater.
Antenna Switch
Repeater TX /RX
GPIO Pins
Major Alarm Pin
Repeater TX /RX
GPIO Pins
Repeater Disabled
Primary Repeater Standby Repeater
Figure 2-19
When a major alarm happens three times in the primary repeater and the repeater enters the locked state, the primary repeater will set the major alarm GPIO pin to active level. The standby repeater detects the disable pin is changed to inactive level and it becomes enabled. The antenna switch is also triggered which changes the antenna to the now active repeater.
Once the fault in the primary repeater is addressed, the repeater is removed from the locked state and reset, the primary repeater will enabled and again become the primary repeater. The standby repeater will become disabled.
November, 2008
76 System Feature Overview
If repeaters are operating in IP site Connect mode, they must both have existing IP network connections and be communicating with the Master. Since they are both on the network, they must have different IP Addresses. Although the system will not send voice to a disabled repeater, it will require link management. Make sure to take this into consideration when planning for
network bandwidth, See “Required Bandwidth Calculations” on page 163 for details on calculating
the bandwidth. Note that a redundant repeater connected to the IP Site Connect system counts in the total number of supported peers.
It is also important to note that when setting up the Master repeater of an IP Site Connect system into a redundant configuration, the network link must also be switched with external hardware similar to that of an RF Antenna. In this case, the IP Address of both the Primary and the Standby repeaters must be the same since all the Peers communicate with it using this IP address. As they have the same IP Address, they cannot be connected to the network at the same time. This also means that the standby repeater can be contacted via a network RDAC application while not in the primary repeater role since it is not connected to the network. Because the two devices have the same IP address but different MAC addresses, Peers may not be able to contact the Master repeater until the router and repeater ARP tables are updated. Depending on router configuration this could take up to 15 to 20 minutes. It is recommended to consult the Network Administrator for details on setting the ARP interval within the customer’s network.
2.8.5 Dual Control Considerations
It is possible to have RDAC connected locally, over the network, and connected via GPIO lines simultaneously to a single repeater. In this case, the repeater can be controlled through GPIO as well as through the network. The user should be aware that it is not recommend using both methods to control the repeater at the same time. Note that after a control command has being executed from RDAC application, the control console connected via GPIO may no longer indicate the state of the repeater correctly since it will be reading the state of the hardware pin rather than the internal repeater state. In other words if the external application has pulled a pin low or high, the repeater cannot change the level of that pin after RDAC has made a change.
November, 2008
System Feature Overview 77
2.9 Voice Operated Transmission (VOX)
MOTOTRBO provides the ability for hands-free radio transmissions with select radio accessories.
2.9.1 Operational Description
Voice Operated Transmission (VOX) monitors the accessory microphone for voice activity. When voice is detected, the radio is keyed-up and the voice is transmitted. When voice is no longer detected at the accessory microphone, the radio is de-keyed.
2.9.2 Usage Consideration
There are several considerations that should be made when VOX is used. First, VOX is designed to key-up and transmit whenever voice is detected. This means that every time the operator speaks the radio will transmit. If the radio operator is in close proximity to another person, the radio may detect the other person’s voice and begin transmitting. The successful use of VOX requires the radio operator to be aware of any possible audio sources that may inadvertently cause the radio to transmit at an undesirable time.
Second, the use position of the VOX accessory is an important factor in using VOX successfully.
The radio operator should position the accessory so that it can pickup the operators voice with a minimal amount of ambient noise.
Additional consideration is needed as outlined in the following sections.
2.9.2.1 Suspending VOX
In those situations when VOX may not be desired, the radio operator can temporarily suspend
VOX by pressing PTT. The radio will immediately suspend VOX and key-up the transmitter.
Traditional (i.e. non-VOX) radio behavior will be used for any following transmissions. VOX operation will be resumed if the channel is changed (and changed back), the radio is power cycled, or the user re-enables VOX using the menu or a designated programmable button.
To disable VOX on a channel so that VOX behavior does not resume after a power-cycle or channel change, the menu or the designated programmable button must be used.
2.9.2.2 Talk Permit Tone
When VOX is used in conjunction with the Talk-Permit-Tone (TPT), the expected behavior of the radio should be understood. When TPT’s are disabled the radio operator may begin speaking and the radio will immediately key-up and transmit the entire phrase uttered by the radio operator.
However, when TPT’s are enabled the radio operator must use a trigger word to key-up the radio.
The trigger word will not, in most cases, be transmitted. After uttering the trigger word, the radio operator should wait until after the TPT is heard to begin speaking.
2.9.2.3 Emergency Calls
When a radio operator presses the Emergency Alarm button on a VOX-enabled channel, VOX is temporarily suspended so that the radio operator can handle the emergency situation. VOX
November, 2008
78 System Feature Overview operation will automatically resume once the emergency has been cleared. If at any time during the emergency the radio operator presses PTT, VOX operation will not automatically resume after
the emergency is cleared. See “Suspending VOX” on page 77 for instructions on how to resume
VOX.
2.10 Analog Features
For customers that are migrating from Analog systems to Digital systems, MOTOTRBO supports both analog and digital modes of operation. MOTOTRBO mobile and portable radios support both analog and digital modes (the user can select which mode to use, and change modes dynamically), while MOTOTRBO repeaters are configured to operate in digital mode or in analog mode. When in Analog mode, MOTOTRBO utilizes traditional FM technology, supports both 12.5
and 25kHz channel spacings, and can operate in repeater and direct modes.
2.10.1 Analog Voice Features
The following traditional Analog features are supported by the MOTOTRBO system:
Feature Name
Time-Out Timer
Squelch
Monitor/Permanent
Monitor
Talkaround
12.5/25kHz
Configurable Bandwidth
PL/DPL
Channel Access Control
Description
Sets the amount of time that the radio can continuously transmit before the transmission is automatically terminated.
Special electronic circuitry added to the receiver of a radio which reduces or squelches, unwanted signals before they are heard through the speaker.
The user can check channel activity by pressing the Monitor button. If the channel is clear, the user hears static. If the channel is in use, the user hears the conversation. It also serves as a way to check the volume level of the radio, as while pressing the monitor button, the user can adjust the volume according to the volume of the static/conversation heard.
This feature allows a user to talk directly to another unit for easy local unitto-unit communications and bypass the repeater.
Channels on the radio can be programmed through the CPS to operate at either 12.5kHz or 25kHz.
Transmitted when the receiving radio is to only receive calls from radios with specific PL/DPL codes, this creates communications groups while operating in Conventional Dispatch mode. PL/DPL allows for more privacy on a frequency. PL/DPL is transmitted as a sub-audible frequency or a digital code.
This feature dictates what conditions a radio is allowed to initiate a transmission on a channel. There are three possible values which are
Always, Channel Free, and Correct PL. Refer to “MOTOTRBO Channel
Access” on page 16 for more details.
November, 2008
System Feature Overview
2.10.2 MDC Analog Signaling Features
MOTOTRBO contains a limited set of built-in MDC signaling features. These include:
Feature Name
Emergency Signaling
PTT-ID
Call Alert
Description
Sends a help signal to a pre-defined person or group of people. The emergency feature also allows a user to sound an alarm or alert the dispatcher in an emergency situation. The user is also able to acknowledge an emergency.
PTT-ID identifies the user’s outgoing calls on other users’ radios.
Call Alert notifies the radio user of incoming calls if they are a short distance away from their radio. Call Alert also informs unavailable users that someone is trying to reach them.
2.10.3 Analog Scan Features
Feature Name
Nuisance Channel
Delete
Priority/Dual Priority
Scan
Tone Private Line
Lockout
Talkback Scan with
Home Channel Revert
Description
A channel with unwanted activity is called a Nuisance Channel. The user can remove a Nuisance Channel from the Scan List temporarily by using the Nuisance Channel Delete feature.
Priority Scan allows a user to program the radio to scan more frequently transmissions on the most important channel, and ensure they do not miss critical calls. Dual Priority Scan allows a user to program a radio to frequently scan transmissions on the two most important channels, and ensure they do not miss critical calls.
During scan, if activity is detected on a channel, but does not match the un-muting condition, lockout occurs. Once lockout occurs, the radio ignores activity on that channel for the next nine scan cycles. However, if scan finds that activity has ceased on that channel, the counter is reset and is no longer ignored.
Talkback scan allows activity on different communications channels to be monitored and answered. Home channel revert allows a user to automatically access a preferred channel.
79
November, 2008
80 System Feature Overview
2.10.4 Analog Repeater Interface
To facilitate the migration from analog to digital, the MOTOTRBO repeater offers an analog repeater interface that allows the repeater to operate with legacy analog accessories.
The interface is configurable via the CPS and can support the following applications:
1. Tone panels
2. Phone Patches
3. Console Desksets connected via a local interface
4. Console Dispatcher in base station configuration
5. Trunking controllers such as LTR and PassPort
2.10.4.1 Analog Repeater Interface Settings
The analog repeater interface is configurable via the CPS. The CPS offers repeater-wide settings as well as programmable input and output pins on the rear accessory connector.
November, 2008
System Feature Overview 81
2.10.4.1.1CPS Repeater Wide Settings
CPS Repeater
Control Name
Audio Type
Analog Accessory
Emphasis
Audio Priority
Disable Repeat Path
Description
“Filtered Squelch” configures the repeater so that only the audible frequency spectrum (300 Hz – 3 kHz) is sent to the rear receive audio pin/speakers as well as transmitted over the air. The user in deskset controller applications is interested in this audible frequency spectrum.
“Flat Unsquelch” should be used in applications such as trunking controllers or community repeaters where there is sub-audible signaling that needs to be passed. In this configuration, the repeater will pass the audio unfiltered over the air as well as to the rear receive audio pin and speakers. The filtering is performed in the external device, not in the repeater.
Pre-emphasis is configurable on transmitting subscribers. In order to match the emphasis settings on the wireline, de-emphasis on the receive path and preemphasis on the transmit path of the analog repeater interface can be enabled or disabled.
This setting is in addition to the repeater’s Emphasis setting. Furthermore, when Audio Type is set to “Flat Unsquelch”, there is no emphasis in the audio.
This setting determines if “External PTT” or “Repeat Path” has priority over the transmitter when Disable Repeat Path is disabled. A priority of None implies the transmitter will be granted on a first come first served basis.
Some applications do not want the repeater to perform in-cabinet repeat; they warrant that the external PTT be the only input that can trigger the repeater to transmit. This setting configures the repeater to only transmit when the PTT is asserted.
2.10.4.1.2Rear Accessory Port CPS Programmable Pins
The rear accessory also has some pins that can be programmed to specific input/output functions.
These pins can be programmed to either active high or low.
CPS Programmable
Pins
PTT
CSQ Detect
PL Detect
Description
PTT can be programmed to any programmable pin on the rear accessory connector.
Squelch detect will toggle this output pin on. Loss of squelch will toggle this output pin off.
A signal meeting the PL rules programmed in the channel toggles this output pin to its active state. Loss of the PL signal toggles the output pin to its inactive state.
November, 2008
82 System Feature Overview
CPS Programmable
Pins
Monitor
Repeater Knockdown
Antenna Relay
Description
Asserting this input pin reverts the receiver to carrier squelch operation.
Upon detection of RF signal, the repeater enables the Rx Audio lines and unmutes the speaker.
Asserting this input pin triggers the repeater to temporarily enter Repeat
Path Disable Mode. In this mode, the repeater’s transmitter will only be enabled by the external PTT and the audio source will be the Tx Audio
Input pin.
Releasing this input pin will revert the repeater back to Normal Mode where the repeaters transmitter can be activated by a qualified RF signal on the receive frequency.
This output pin is used to drive an antenna relay switch for applications where the repeater acts as a dispatch station that will only receive or transmit at a time. This allows the use of a single antenna without the need of expensive combining equipment. The pin toggles active when the repeater enters a transmit state, and reverts to inactive when the repeater drops back to idle/receive.
2.10.4.1.3Rear Accessory Port Fixed Audio Pins
One must keep in mind the following regarding the fixed audio pins on the rear accessory connector.
Fixed Pins
Spkr+/Spkr-
Rx Aud
Tx Aud
Description
Act as a differential pair and should be connected at opposite ends of an audio speaker or equivalent load. Under rated conditions, the output voltage will be 7.75V RMS and the radio supports impedances down to 4 ohms with distortion typically less than 3%. The internal speaker is connected in parallel with the external output and is 20 ohms. This must be kept in calculations of load impedance and can only be removed by physically disconnecting the speaker inside the control head. Under no conditions should either of these two outputs be connected to ground.
Provides a line level audio output at 330mV RMS under rated conditions.
The frequency response of this output has been extended below 300Hz to support data transfer for specific applications (Flat Unsquelch).
Accepts transmit audio at 80mV RMS through a 560 ohm load. Care must be taken when choosing an audio source as the output impedance of the source can affect the audio level which may need to be adjusted accordingly.
November, 2008
System Feature Overview 83
2.10.4.2 Configuration Summary Table
The following table gives a high level view of which features of the analog repeater interface are needed to support specific types of accessories. This table is meant to act only as a guideline.
Acc Type Trunking
Phone
Patch
RX Audio
TX Audio
Ext PTT
Disable Repeat Path
Repeater Knockdown
Monitor
PL Detect
CSQ Detect
Y
Y
Y
Y
NA
N
N
O
Y
Y
Y
N
Y
Y
O
O
Audio Type
Analog Accessory
Emphasis
Antenna Relay
FLAT
NA
FILTERED
O
NA NA
Y = This feature is necessary for the application
N = This feature is not necessary for the application
O = This is an optional parameter for the application
NA = Not Applicable
Tone
Panel
NA
N
O
O
Y
Y
Y
Y
FLAT
NA
NA
Local
Deskset
O
O
Y
Y
Y
N
Y
Y
FILTERED
O
O
Console
Base
Station
NA
Y
O
O
Y
Y
Y
Y
FILTERED
O
O
2.10.4.3 Configuration Considerations
2.10.4.3.1Trunking Controllers & Community Repeaters
Most analog trunking controllers and community repeaters will have two outputs that are to be modulated by the repeater: voice audio, signaling data. The MOTOTRBO repeater only accepts one audio input. Thus the two outputs must first be mixed into a single input and dropped down to the audio level the MOTOTRBO repeater expects on the microphone port.
The microphone port is designed to transmit audio at 80mV RMS (220 mV P-P) through a 560 ohm load. Care must be taken when choosing an audio source as the output impedance of the source can affect the audio level which may need to be adjusted accordingly.
When mixing the audio and signaling, care must also be taken to determine the expected deviation of the signaling. For example, in LTR controllers, the expected deviation of the LTR data is
~800Hz. Please refer to your controller’s user manual which gives guidance on how to tune the data signal output to achieve adequate data deviation.
November, 2008
84 System Feature Overview
Similar to existing cables, resistors can be placed on the cable to drop the level coming out from the controller (on the order of 1-2 V P-P) to the level expected by the transmit audio pin. Once the resistor value is determined, the audio and signaling signals can be mixed into a single wire that can be crimped onto the MOTOTRBO accessory connector (Motorola Part Number PMLN5072_).
2.10.4.3.2Zetron Controllers
The following are the Zetron configurations needed that will enable Zetron controllers to interface with the MOTOTRBO repeater.
Pin 1
Pin 3
Pin 7
Pin 10
Zetron
Pin 11
12VDC
GND
*PTT (N.O. Relay)
Squelch
TX Audio
MOTOTRBO
Pin 7
Pin 8
Pin 17
Pin 22
Pin 11
3.3k
Pin 12
TX Audio GND
Pin 12
Pin 13
LTR TX Data
3.3k
Pin 14
Pin 15
DISC. GND
DISC Audio
Pin 18
Pin 14
Figure 2-20 Cable Schematic for Zetron Controllers
Schematic Notes:
• On the Zetron connector, pin 6 is PTT Common, this must be jumpered to one of the grounds. This is the common pin of the PTT relay. Without this, the unit will not key-up.
• Use a shielded cable for Discriminator Audio.
• The two 3.3k ohm resistors need to be mounted at the MOTOTRBO end of the cable.
• Large arrows indicate signal/function flow.
• Please note that Pin 17 (PTT) and Pin 22 (Squelch/CSQ Detect) need to be provisioned in the CPS.
November, 2008
System Feature Overview
The following table lists the jumper/switch settings for trunking/tone panel controllers.
Zetron Model 42 Trunking Controller Jumper Settings
JP1 set to ‘B’ (Flat)
JP2 set to ‘A’ (Tone Flat)
JP3 set to ‘A’ (Sub Out High)
JP4 set to ‘A’ (+20dB Receive Audio Gain)
JP6 set to ‘A’ (TX Audio Level High)
JP7 set to ‘Ext Sq +’ (pins 5-7 and 6-8 jumpered)
NOTE: If you have an older Zetron controller that will be used in a 12.5kHz system for the first time, make sure it has first been modified for 12.5kHz operation. See Zetron’s supplemental publication: 011-0509 for instructions on making this modification.
85
Zetron Model 49 Trunking Controller Jumper Settings
JP1 set to ‘A’ (Flat Audio)
JP2 set to ‘A’ (Tone Flat)
JP7 set to ‘A’ (COR as input)
JP9 set to ‘A’ (+20dB Receive Audio Gain)
JP10 set to ‘A’ (TX Audio Level High)
JP12 set to ‘Ext Sq +’ (pins 5-7 and 6-8 jumpered)
JP13 set to ‘B’ (HP Filter IN)
JP23 set to ‘A’ (Sub In from Disc.: pins 1-2 and 3-4 jumpered (grounds pin 4 on rear connector))
JP24 set to ‘A’ (Sub Out DC coupling)
JP25 set to ‘A’ (Sub Out High)
JP26 set to ‘A’ (Sub Out analog)
WARNING: Pin 4 of the rear connector is listed as a ground. But it will not be grounded unless JP23 is set for it. This pin also acts as an input for the receive LTR data path. See jumper table below.
NOTE: The jumpers do not follow standard positioning. Some may be vertical, some may have position ‘A’ on the left, some may have position ‘B’ on the left. Take extra care when making these settings.
NOTE: If you have an older Zetron controller that will be used in a 12.5kHz system for the first time, make sure it has first been modified for 12.5kHz operation. See Zetron’s supplemental publication: 011-0509 for instructions on making this modification.
NOTE: For transmit audio alignment, the Zetron Model 49 manual calls for setting the Tone
Generator at TP4 for 1.4Vp-p/495mv RMS, then adjusting the TX audio for 2kHz deviation (40% of full system deviation). This is for a 25kHz BW system. For 12.5kHz
BW, this adjustment is 1kHz deviation.
Zetron Model 38 Tone Panel Switch Settings
SW2 set to off (up) Audio Output Gain (high)
SW3 set to off (up) PL/DPL output Gain (high)
SW4 set to off (up) Flat/De-emphasis (Flat)
SW6 set to off (up) Internal/External Squelch (External)
SW7 set to on (Down) COR Positive/Negative (Negative)
November, 2008
86 System Feature Overview
Tone Panel Programming Note:
It may be necessary to set the generated DPL (DCS) signal to “Invert” from the tone panel to be recognized by the user radios. These DTMF commands are 3750 for normal and 3751 for inverted signal generation.
Once the above cable and jumper/switch settings have been achieved, you should now be able to refer to the specific controller product manual to complete installation.
2.10.4.3.3 Trident Controllers
Trident MicroSystems manufactures a cable that interfaces Trident Controllers with MOTOTRBO repeaters and provides jumper settings for Trident Controllers.
2.10.5 Comparison Chart
Below is the table that summarizes the features supported by the MOTOTRBO Display Portable with GPS (DM 3601).
Feature Name
Talkaround/Repeater Mode Operation
12.5/25kHz Configurable Bandwidth
PL/DPL Codes
Squelch
Monitor
Time-Out Timer
Channel Access Control
Option Board Expandability
Analog Signaling Features
Quik-Call II
DTMF Encode/Decode
MDC-1200 Call Alert
MDC-1200 Selective Call
MDC-1200 PTT ID
MDC-1200 Emergency
MDC-1200 Selective Radio Inhibit
MDC-1200 Radio Check
DM 3601
X
X
X
X
X
X
X
X
–
Encode
Encode/Decode
–
Encode/Decode
Encode/Decode
–
–
November, 2008
System Feature Overview
Feature Name
MDC-1200 Remote Monitor
Digital Signaling Features
Call Alert
Private Call
Emergency
Selective Radio Inhibit
Radio Check
Remote Monitor
DM 3601
–
Encode/Decode
Encode/Decode
Encode/Decode
Encode/Decode
Encode/Decode
Encode/Decode
Analog Scan Features
Scan
Nuisance Channel Delete
Priority Scan
X
X
X
Dual Priority Scan X
Digital Scan Features
Scan
Nuisance Channel Delete
Priority Scan (Talkaround)
Priority Scan (Repeater Mode)
Dual Priority Scan (Talkaround)
Dual Priority Scan (Repeater Mode)
Mixed Mode Scan Features
Scan
Nuisance Channel Delete
Priority Scan
Dual Priority Scan
X
X
–
–
X
X
X
Future
X
Future
87
November, 2008
88 System Feature Overview
2.11 Third Party Application Partner Program
The MOTOTRBO system is complete and robust enough to fulfill the diverse needs faced by a variety of customers. However, realizing the important role third party developers play in supporting market growth by creating customized applications that add value to customers in different vertical applications, Motorola provides a powerful suite of capabilities to enable third party applications to developers who are members of the Third Party Application Partner Program.
2.11.1 MOTOTRBO, the Dealer, and the Accredited Third-Party
Developer
A third-party developer that joins the Third Party Application Partner Program is accredited and offered technical support from Motorola in the form of getting access to protocol, Application
Programming Interface (API) documentation, online support, as well as to Motorola channel partners and customers. With this in mind, the dealer can sell MOTOTRBO as it is to customers or the system can be modified by a third party developer (Third Party Application Partner Program member) to satisfy a broader range of customer needs and applications.
2.11.2 MOTOTRBO Applications Interfaces
The following applications interfaces are available to PC-based and non-PC based peripherals.
• Text Messaging
• Telemetry
• IP Data Services
• Location Services
• Radio Command and Control (XCMP/XNL)
• Automatic Registration Service
These interfaces utilize the USB interface on the side accessory connector of the MOTOTRBO portable radio, and on the front and rear accessory connectors of the MOTOTRBO mobile radio.
The following capabilities are available to "core" or traditional peripherals.
• receive audio
• transmit audio
• basic control lines (e.g. PTT, Receive unsquelch, etc.)
These interfaces utilize the audio and control lines on the side accessory connector of the
MOTOTRBO portable radio, and on the front and rear accessory connectors of the MOTOTRBO mobile radio. Detailed specifications are available in the respective product service manuals.
NOTE: Option boards enable a third party to embed an application into the MOTOTRBO mobile and/or portable radios, and utilize third party provided hardware and software. Option boards can control the radio through the internal option board interface, as well as interact with external (e.g. PC-based) applications.
November, 2008
System Feature Overview 89
2.11.3 MOTOTRBO Documents Available via the Third Party
Application Partner Program
Each of the interfaces mention in “MOTOTRBO Applications Interfaces” on page 88 is described in
detail in the supporting Application Developers Kit (ADK) documentation listed below. These ADKs are available from the MOTODEV website and on EMEA Motorola Online.
MOTOTRBO Interface
General
MOTOTRBO Option Board
MOTOTRBO XCMP/XNL
MOTOTRBO Telemetry
MOTOTRBO Location Data
MOTOTRBO Text Messaging
MOTOTRBO Peripheral
Other
Application Development Kit
MOTOTRBO ADK Overview
MOTOTRBO Option Board ADK Guide
MOTOTRBO Option Board PROIS Cross-
Reference
Motorola Standard 10S10628A
Motorola Standard 10S11004A
MOTOTRBO XCMP/XNL Development Guide
MOTOTRBO XCMP/XNL Development
Specification
MOTOTRBO Telemetry ADK Guide
MOTOTRBO Telemetry Protocol Specification
MOTOTRBO Location Data ADK Guide
MOTOTRBO Location Request and Response
Protocol Specification
Motorola Binary XML Encoding Specification
MOTOTRBO Text Messaging ADK Guide
MOTOTRBO Text Messaging Protocol Specification
MOTOTRBO XCMP-Based IP Capable Peripheral
ADK Guide
MOTOTRBO Non-IP Capable Peripheral ADK
Guide
MOTOTRBO Third Party Peripheral Cable ADK
Guide
MOTOTRBO Data Services Overview
MOTOTRBO ARS Protocol Specification
November, 2008
90 System Feature Overview
2.11.4 Available Levels of Partnership
The below list briefly details the different levels of partnership available to third-party developers who wish to join the Third Party Application Partner Program.
Level of Partnership
Registered User
Licensed Developer
Application Partner
Level of Partnership
Registered User
Licensed Developer
Description
Provided access to non-proprietary documents.
For developers looking for general information with no specific application planned.
Provided access to non-proprietary documents and additional access to Application Development Kits
(ADKs).
Requires License Agreement.
Level 1 Vendor capability assessment.
For new developers of developers with one-time applications planned.
Provided access to non-proprietary documents,
Application Development Kits (ADKs) and additional access to Motorola’s Marketing Support and User Forums, access to use the Motorola logo, and listed as a Motorola partner on the MOTODEV website.
Requires License Agreement and accreditation by regional ADP manager.
Level 2 Vendor capability assessment.
For developers with proven applications.
Description
Provided access to non-proprietary documents.
For developers looking for general information about the partner program, available applications and solutions and the process on “How to become a Partner.”.
Provided access to non-proprietary documents and additional access to Application Development Kits
(ADKs), technical support, user forums, and use of the Motorola “Licensed Developer” logo.
Requires License Agreement and accreditation by regional Third Party Application Partner Program manager.
Level 1 Vendor capability assessment.
For new developers or developers with one-time applications planned.
November, 2008
System Feature Overview 91
Level of Partnership
Application Partner
Description
Provided access to non-proprietary documents,
Application Development Kits (ADKs) and additional access to Motorola’s Marketing Support and User Forums, access to use the Motorola
“Application Partner” logo, and listed as a Motorola
Application Partner on the EMEA Motorola Online and the MOTODEV website.
Requires License Agreement and accreditation by regional Third Party Application Partner Program manager.
Level 2 Vendor capability assessment.
For developers with proven applications.
For further information, to access the ADKs, or to sign up for the Third Party Application Partner
Program, please visit the MOTODEV Application Developers website at: http://developer.motorola.com
November, 2008
92
Notes
System Feature Overview
November, 2008
System Components and Topologies
SECTION 3 SYSTEM COMPONENTS AND
TOPOLOGIES
93
3.1 System Components
MOTOTRBO consists of numerous components and applications that function together in a system. The first step in designing a system that satisfies the customer’s needs is identifying the devices and applications within the system, and then choosing a basic system configuration of how these components will be interconnected. This section defines the different components and applications available, their offered services, and their roles in the system. We will then describe some of the standard system topologies that MOTOTRBO supports.
Please note that all data application modules contained in this system planner are depictions of typical third party data application modules and have been included simply to illustrate certain
MOTOTRBO application enabling features.
3.1.1 Fixed End Components
The system contains devices with fixed locations and other devices that are mobile. This subsection covers the devices with fixed locations.
3.1.1.1 Repeater
The MOTOTRBO repeater provides an RF interface to the field subscribers. The repeater is AC powered and designed to be discreetly mounted on a standard 19” rack found in most communication tower locations. It offers front panel indicators of its current status including real time transmit and receive indicators for each time slot. Once configured through the Customer
Programming Software (CPS), the repeater is designed to operate behind the scenes and without the need for further user interaction.
The repeater can either be configured as a standalone repeater or as a repeater connected to a back-end network, as in the case of IP Site Connect mode. As a repeater, it listens on one uplink frequency, and then re-transmits on a downlink frequency. Therefore a pair of RF frequencies is required for each repeater in the system.
A major advantage of using a repeater in the system is that it allows a greater communication range than would be possible talking from subscriber to subscriber. Multiple repeaters can be installed in strategic locations for the users’ coverage to be consistent throughout their required range of operation. However, only in IP Site Connect mode, do the radios seamlessly roam between repeaters. In digital repeater mode, the users must know the coverage range provided by each repeater, and manually switch channels when necessary.
The repeater is capable of operating in either digital mode or analog mode. This is determined at the initial configuration, and is not updated dynamically. Therefore at any given time, it either operates as a digital repeater or as an analog repeater.
When configured for analog operation, the repeater is designed to operate with existing analog systems, therefore making migration to a MOTOTRBO system smoother.
November, 2008
94 System Components and Topologies
When configured for digital operation, the repeater offers additional services. The digital repeater operates in TDMA mode, which essentially divides one channel into two virtual channels using time slots; therefore the user capacity is doubled. The repeater utilizes embedded signaling to inform the field radios of the busy/idle status of each channel (time slot), the type of traffic, and even the source and destination information.
Another advantage during digital operation is error detection and correction. The further a transmission travels, the more predominant the interference becomes, and inevitably more errors are introduced. The receiving MOTOTRBO radio, operating in digital mode, utilizes built-in error detection and correction algorithms, native to the protocol, to correct these problems. The
MOTOTRBO repeater uses the same algorithms to correct the errors prior to retransmission, thus repairing any errors that occur on the uplink; it then transmits the repaired signal on the downlink.
This greatly increases the reliability and audio quality in the system, which increases the customer’s coverage area.
In digital mode, the repeater only retransmits digital signals from radios configured with the same system identifier. This aids in preventing co-system interference. The repeater does not block transmissions of radios within its own system.
As previously described, the repeater utilizes embedded signaling to announce the current status of each channel. It is up to the radios in the field to interpret these signals, and grant or deny their user’s request for transmission. Therefore, when a user or a group of users utilizes a channel (time slot), the repeater announces that the channel is being used and who is using it. Only radios that are part of that group are allowed to transmit. The repeater additionally allows a short duration of reserved time after a transmission. This allows other users in the group to respond to the originator. This reserved hang time greatly improves the continuity of calls, because new calls cannot start until the previous call ends. Without this feature, users may experience delays in responses (that is, between transmissions of calls), due to other calls taking over the channel inbetween their transmissions.
After this reserved hang time, the repeater continues to monitor for a short period. If no user transmits on the channel for a duration of time, the repeater stops transmitting. When the next radio transmission occurs, the repeater begins repeating again.
In IP Site Connect mode, the repeaters perform the following additional duties:
• Each repeater ensures that their communication links with other repeaters are open all the time.
• They inform their operating status (including IPv4/UDP address) to each other.
• They ensure that in cases of multiple calls starting within a short period, only one call prevails at all the sites and all of them (except those that detect interference) repeat the selected call.
• They inform their alarm conditions and provide diagnostic information to the RDAC-IP tool.
The RDAC-IP tool allows its user to remotely change the mode of a repeater.
November, 2008
System Components and Topologies 95
3.1.1.1.1 Repeater Specifications
The MOTOTRBO repeater is currently available in 12.5kHz or 25kHz operation in analog, or
12.5kHz in digital. The table below shows the available repeater bands and associated power levels that are currently supported.
Dimensions
(h x l x w)
Weight
5.25"x11.75"x19" 14 KG.
Power Requirements
Voltage and
Current
Power
100-240 Volts AC, 1A while on standby, 4A while transmitting
UHF 1 UHF 2
1 – 25 Watts
1 – 40 Watts
(up to
512 MHz)
25 – 40 Watts 1 – 25 Watts
(above
512 MHz)
VHF
1 – 25 Watts
25 – 45 Watts
3.1.1.2 Radio Control Station
The MOTOTRBO Control Station is based on the MOTOTRBO Mobile, except that it is configured to be the RF link from the data application server to the repeater and other radios. It is integrated with an AC power supply and appropriate housing to be placed on a desk. Since it is the radio gateway to the server, it is configured to transmit and receive on a single channel. It is programmed with a known radio ID, so that field radios know how to contact the server. In a
MOTOTRBO system, there can be up to four control stations connected via four USB ports; each control station communicates through a separate logical channel.
In most cases, the Control Station is externally controlled by the PC. It requires no user interaction once programmed. However, if a situation requires the use of a control station to transmit voice, it is capable of transmitting voice as well.
3.1.1.3 MC1000, MC2000, MC2500 Console
The MOTOTRBO mobile in analog mode supports the MC Deskset Series of consoles. The MC
Deskset Series provides a complete portfolio of products for a small control room. Each unit provides control of the radio(s) via a compact desk unit offering a choice of control methods: Local and Remote. The portfolio ranges from a simple talk and listen unit to a miniature multi-channel console.
The MC1000 can control a single control station, and provides a selection of up to four frequencies. This unit requires no software for programming.
The MC2000 can also control a single control station, but provides a selection of up to 16 frequencies. Programming this unit is through configuration software installed on a PC.
The MC2500 controls up to 4 control stations, with the ability to patch and multi-select channels.
All channels are capable of 16 frequency controls. This unit is programmed through configuration software installed on a PC.
November, 2008
96 System Components and Topologies
Each unit ships with a power supply and manual. The MC1000 ships with a 110V, 60Hz unit, while the MC2000/MC2500 ship with an 110/220V, 50/60Hz unit.
The MOTOTRBO mobile can be interfaced with the MC1000, MC2000 and MC2500 Desktop
Consoles. These consoles allow for remote and local access to the MOTOTRBO Control Station.
The interface to the console uses a 26-pin MAP connector. The console interface to the control station consists of TX_Audio, RX_Audio, PTT, Monitor and Channel Activity. Additionally, channel steering is provided by the mobile radio through the GPIO pins, which are configurable using the
CPS. Advanced MDC commands are only supported in analog mode and a not in digital mode.
Please refer to the analog console installation manual for more details on analog console configurations.
3.1.2 Mobile Components
Most users of the MOTOTRBO system will be utilizing mobile devices (non-fixed) to access the system. Below are the devices currently available in the following frequency ranges and power levels.
The MOTOTRBO portable is currently available in the following frequency ranges and power levels:
Freq. Band
UHF 1
UHF 2
VHF
Frequency Range
403 – 470 MHz
450 – 512 MHz
136 – 174 MHz
Power Level
1 – 4 Watts
1 – 4 Watts
1 – 5 Watts
The MOTOTRBO mobile is currently available in the following frequency ranges and power levels:
Freq. Band
UHF 1
UHF 2
VHF
Frequency Range
403 – 470 MHz
450 – 527 MHz
136 – 174 MHz
Power Level
1 – 25 Watts
25 – 40 Watts
1 – 40 Watts
(for 450 – 512 MHz)
1 – 25 Watts
(for 512 – 527 MHz)
1 – 25 Watts
25 – 45 Watts
3.1.2.1 MOTOTRBO Portable
The MOTOTRBO portable is a durable, but lightweight radio that offers many ways to access the system’s features. It is designed to allow users to take it with them anywhere, and yet remain connected to the system.
November, 2008
System Components and Topologies 97
The following table lists the average battery life at 5/5/90 duty cycle with battery saver enabled, performing with carrier squelch, and transmitting at high power:
Battery Type
NiMH Battery
IMPRES Li-ion Slim Battery
(Standard)
IMPRES FM Li-ion Battery
Battery Life
Analog : 8 Hours
Digital : 11.2 Hours
Analog : 9.3 Hours
Digital : 13 Hours
Analog : 8.7 Hours
Digital : 12.1 Hours
The portable is available in two tiers:
• A keypad radio with display, and
• A non-keypad radio with no display.
The portable is fully configurable via the Windows-based CPS. It can be programmed to allow access to all MOTOTRBO features and all channels within the system or can be simplified to only allow limited access. The MOTOTRBO portable can truly be configured to cater to your customer’s needs.
November, 2008
98
3.1.2.1.1 User Interface
System Components and Topologies
Channel Selector Knob
Antenna
On/Off/Volume Control Knob
LED Indicator
Side Button 1
Push-to-Talk (PTT) Button
Side Button 2
Side Button 3
Front Button P1
Microphone
Emergency Button
Universal Connector for Accessories
Display
Menu Navigation Keys
Keypad
Front Button P2
Speaker
Figure 3-1 MOTOTRBO Portable (Display Model)
Channel Selector Knob
On/Off/Volume Control Knob
LED Indicator
Side Button 1
Push-to-Talk (PTT) Button
Side Button 2
Side Button 3
Antenna
Emergency Button
Universal Connector for Accessories
Speaker
Microphone
Figure 3-2 MOTOTRBO Portable (Non-Display Model)
November, 2008
System Components and Topologies 99
The primary buttons of the MOTOTRBO portable offer the user the ability to initiate most system features. These buttons and switches should be very familiar to radio users.
Push-to-Talk Button
The large round Push-To-Talk button, or PTT button, is the primary button used to initiate voice transmissions. Its location is on the left side of the portable, but is still easy to reach for both righthanded or left-handed users. The button is raised from the side and has a raised pattern, so that it is easily found even under low light conditions. Pressing the PTT button starts a voice transmission on the selected channel. This enables the user to simply push and talk.
Channel Selector Knob
The MOTOTRBO portable user chooses his communication environment by twisting the 16 position channel knob on the top of the portable radio. This Channel Selector Knob is the main way a user uses to access the system. It also has a raised pattern, so it too is easy to find under low light conditions. Although easy to find, it is designed to require some force to turn it, so as not to be accidentally rotated through normal user activities. Each knob position can be programmed to access a different channel within the radio’s programming. This allows the user to quickly switch between analog and digital channels and even different groups.
But the user is not limited to 16 channels. He can place up to 16 channels into a zone, and then switch between multiple zones. This greatly increases the number of available channels to the user.
Programmable Buttons
There are programmable buttons on the MOTOTRBO portable. The display portable has 6 programmable buttons, while the non-display portable only has 4 programmable buttons. Each button can be programmed to perform a particular function. The short press and long press can be programmed to act differently. The orange button located on the top of the radio is commonly used to initiate emergency alarms, although it can be configured to function differently.
Status Indicators
There are a few different ways to provide feedback to the user. Depending on its color and state, a large tri-colored LED on the top of the radio indicates whether the radio is transmitting or receiving, and whether the selected channel is busy or idle. The LED busy indication represents the presence of RF activity on the selected channel and is not specific to the digital slot currently being monitored. The MOTOTRBO keypad portable with display also has a two-line LCD that displays a wide variety of information including received signal strength, battery power, emergency status, received text message indicator, monitor on/off, and GPS status. This display also allows each channel name to be displayed, so that the user knows the name of the selected channel. The source ID and target group alias are also displayed. User names are kept in an address book. This allows the user to assign user-friendly names as aliases to a radio ID. Various alert tones, talk permit tones and keypad tones are also available to give additional audio feedback to the user.
Menu System
In addition to accessing system features via buttons, the MOTOTRBO keypad portable with display offers a menu shown on its two line LCD display. With use of a menu button, left and right arrow buttons, a back/home button, and an OK button for selection, users can easily navigate through the following additional features.
November, 2008
100 System Components and Topologies
• Contacts
• Scan
• Messages
• Call Logs
• Utilities
For further details on these menus, please see the MOTOTRBO portable user manual.
Full Keypad
The MOTOTRBO keypad portable with display offers a full numeric keypad for users to manually enter target addresses for system features. This keypad is also used as an alphanumeric keyboard for text messaging. The non-display portable does not come with a keypad.
3.1.2.1.2 Voice Feature Support
With use of the MOTOTRBO portable interface, the user has access to all the voice features the
MOTOTRBO system as to offer. These features include Group Calls, Individual Calls, All Calls, and Emergency Calls.
3.1.2.1.3 Command and Control Feature Support
Command and control system features like Radio Check, Call Alert, Remote Monitor, Radio
Enable/Disable are all accessible from the MOTOTRBO portable’s user interface.
3.1.2.1.4 Analog Compatibility
The radios can be programmed to support many current analog system features. Supported analog features include:
• Analog communications on a 12.5/25kHz channel (as standard),
• Private-Line (PL) and Digital Private-Line (DPL) coded squelch control (as standard),
• MDC signaling.
3.1.2.1.5 Integrated GPS Antenna and Receiver
The MOTOTRBO portable can contain an internal GPS receiver that works with the Location
Services / Tracking Data Application. The location application and radio can be configured so that the radio transmits its location to a centralized application. The GPS antenna is integrated into the portable’s main antenna. In the LCD display on the radio, an icon indicates if the radio is in range of the GPS satellites.
3.1.2.1.6 Text Messaging Compatibility
The MOTOTRBO portable can receive and transmit text messages. These can be Quick Text
(pre-defined) messages already stored on the portable. In the case of keypad radio with display, freeform messages also can be created using the keypad. Through the menu, the user can access the Inbox that contains all the messages he has received. The radio allows a user to send a text
November, 2008
System Components and Topologies 101 message to an individual, a dispatcher or a group of radios. He can also reply to and forward text messages to other radios.
Do note that all the features mentioned apply to the radio’s built-in text messaging as well as to
“mobile on a PC” text messaging.
3.1.2.1.7 Accessory and Peripherals Interface
The MOTOTRBO portable radio supports an improved accessory and peripherals interface. This new interface is Motorola’s platform for future accessory development, and is not compatible with older accessories. It supports the following capabilities:
• Enhanced Audio Functionality – This unique technology enables communication between the radio and Motorola’s enhanced accessories to optimize audio performance. It enables more consistent audio levels between accessory types. So headsets, remote speaker mics, or the radio’s built-in mic and speaker sound more consistent and interoperate more effectively. It also optimizes audio quality performance for a given accessory type, by employing digital signal processing (DSP) technology to best match the radio’s audio signals to the capabilities of the accessory.
• USB Capability – The MOTOTRBO accessory and peripherals interface incorporates the standard Universal Serial Bus (USB) capability, thus enabling IP connectivity via standard
USB ports with personal computers and other peripherals via a Motorola-supplied cable.
This interface supports radio programming capabilities with no Radio-Interface-Box (RIB) required. It also supports third party applications by enabling interfaces for IP data service,
telemetry services, text messaging and location tracking. Refer to “Third Party Application
Partner Program” on page 88 for more details on the Third Party Application Partner
Program .
• Core peripheral – The MOTOTRBO accessory and peripherals interface also includes core functionality for audio input and output, PTT, monitor, receive unsquelch, channel steering, and other general purpose input-output (GPIO) functions. This enables interface with dispatch and telemetry applications and other traditional radio system applications.
• RF input/output – The MOTOTRBO accessory and peripherals interface also includes antenna signal (RF input/out) for use with future accessories such as public safety style microphones and vehicular adaptors.
• Rugged and Submersible – The MOTOTRBO accessory and peripherals interface meets
IP57 requirements (submersible to 1 meter for 30 minutes), thus enabling development of rugged and submersible accessories.
3.1.2.2 MOTOTRBO Mobile
The MOTOTRBO Mobile is designed to be located in a vehicle and powered by the vehicle’s battery or by AC power. Its durable construction makes it safe to use in most in-vehicle environments. It also can be used on desktops that are not truly mobile. Similar to the portable, the mobile offers numerous ways to access the system’s features.
The mobile is available in two tiers:
• A radio with full display, and
• A radio with numeric display.
November, 2008
102 System Components and Topologies
The mobile is fully configurable via the Windows-based configuration software (CPS). It can be programmed to allow access to all MOTOTRBO features and all channels within the system, or can be simplified to only allow limited access. The MOTOTRBO Mobile can truly be configured to cater to your customer’s needs.
3.1.2.2.1 User Interface
Power Button
LED Indicators
Volume Knob
LCD Screen Channel Rocker
P 1
P 2
MENU
O K
BACK
CH+
CH -
P 3
P 4
Mic Connector
Menu Buttons
Programmable Buttons
Speaker
Figure 3-3 MOTOTRBO Mobile Control Head (Full Display Model)
LED Indicators
Power Button Numeric Display
Volume Knob Indicator Icons
Channel Rocker
CH+
CH -
P 1 P 2
Speaker
Mic Connector
Programmable Buttons
Figure 3-4 MOTOTRBO Mobile Control Head (Numeric Display Model)
The primary buttons of the MOTOTRBO Mobile offer the user the ability to initiate most system features. These buttons and switches are the corner stone of the radio and should be very familiar to radio users.
November, 2008
System Components and Topologies 103
Push-to-Talk Button
The Push-To-Talk (PTT) button on the microphone is the primary button used to initiate voice transmissions. The cable connecting the microphone to the mobile is long enough to be comfortably used by either a right handed or left handed user. The button is raised from the side and has a raised pattern so that it is easily found in the low light conditions. Pressing the PTT starts a voice transmission on the selected channel. This enables the user to simply Push and
Talk. The MOTOTRBO mobile can also interface to other accessories such as a Visor
Microphone, a Foot Switch and an enhanced full keypad microphone. Motorola Original™ accessories provide an easy way to turn the MOTOTRBO mobile radio into a custom communication solution to fit your business requirements.
Channel Rocker
The MOTOTRBO Mobile user chooses his communication environment by selecting a channel using the Channel Rocker on the control head. The Channel Rocker has a raised pattern that is backlit so it is easy to find in low light conditions. Although easy to find, it requires some force to push it so as not to change channels through accidentally pressing. Each press can be programmed to access a different channel within the radio’s programming. This allows the user to quickly switch between analog and digital channels and even different groups. The user can quickly switch to different channels by pushing the up or down sections of the rocker. This greatly increases the number of available channels to the user.
Programmable Buttons
There are programmable buttons on the MOTOTRBO mobile. The full display mobile has four programmable buttons while the numeric display mobile has two programmable buttons. Each button can be programmed to perform a particular function. The short press and long press can be programmed to act differently. The buttons can be programmed to give quick and easy access to the MOTOTRBO system features, triggering emergency alarms and operating horns or lights.
Status Indicators
The MOTOTRBO mobile provides a multi-colored LED on the front of the radio that informs the user of the busy or idle status of the selected channel. The LED busy indication represents the presence of RF activity on the selected channel and is not specific to the digital slot currently being monitored. The MOTOTRBO Mobile also provides a two line LCD display that shows a wide variety of information, including received signal strength, battery power, emergency status, monitor on/off, and GPS status. This display allows each channel name to be displayed so that the user knows the name of the selected channel. The source ID and target group alias are also displayed for ease of use. User names are kept in an address book. This allows the user to use familiar names as aliases a radio ID. Various audio alert tones, talk permit tones and keypad tones are available to help the user navigate.
Menu System
In addition to the accessing system features via buttons, the MOTOTRBO Mobile offers a menu shown on its two line LCD display. With use of a menu button, left and right arrow buttons, a back/ home button, and an OK button for selection, users can easily navigate through the following additional features. The Menu includes:
• Contacts
• Scan
November, 2008
104 System Components and Topologies
• Messages
• Call Logs
• Utilities
For further details on these menus, please see the MOTOTRBO mobile user manual.
Full Keypad
As an option, the MOTOTRBO Mobile offers an Enhanced Keypad Microphone so that users can manually enter target addresses for system features. Text messaging from the mobile will be available to the end user if the MOTOTRBO mobile is configured with an Enhanced Keypad
Microphone. The Enhanced Keypad Microphone has a keypad that also doubles as a keyboard for text messaging.
3.1.2.2.2 Voice Feature Support
With use of the MOTOTRBO Mobile interface, the user has access to all the voice features the
MOTOTRBO system as to offer. These features include: Group Calls, Private Calls, All Calls, and
Emergency Calls.
3.1.2.2.3 Command and Control Feature Support
Command and control system features like Radio Check, Call Alert, Remote Monitor, and Radio
Enable/Disable are all accessible from the MOTOTRBO Mobile’s user interface.
3.1.2.2.4 Analog Compatibility
The radios can be programmed to be backwards compatible and can support many current analog system features. These analog channels can be accessed through the Channel Rocker.
Supported analog features include:
• Analog communications on a 12.5/25kHz channel
• Private-Line (PL) and Digital Private-Line (DPL) coded squelch control
• MDC signaling (Emergency, PTT ID and Call Alert)
3.1.2.2.5 Integrated GPS Antenna and Receiver
The MOTOTRBO Mobile can also be purchased to contain an internal GPS receiver that works with the Location services / tracking data application. The location application and radio can be configured so that the radio will transmit its location to a centralized application. The GPS antenna is an external antenna that will have to be mounted on the vehicle. In the LCD display on the radio, an icon will display whether or not the radio is in range of satellites.
3.1.2.2.6 Text Messaging
The MOTOTRBO Mobile can receive and transmit text messages. Through the menu, the user can access an inbox that contains all the messages he has received. When composing a message, the user can generate a free form text message or choose from a list of Quick Text (predefined) messages. The MOTOTRBO radio allows a user to send a text message to an individual,
November, 2008
System Components and Topologies 105 a dispatcher or a group of radios. He can even reply to and forward text messages to other radios.
If the MOTOTRBO mobile is not configured with the Enhanced Keypad Microphone, then text messaging can be accomplished through a mobile computer, running the text messaging client connected to the mobile. Using CPS, the radio can be configured to support text messaging internally or forward data to a mobile computer connected to the radio.
Do note that all the features mentioned apply to the radio’s built-in text messaging as well as to
“mobile on a PC” text messaging.
3.1.2.2.7 Front Panel Accessory Interface
The MOTOTRBO mobile radio supports an improved front panel accessory interface. This new interface is Motorola’s platform for future accessory development and is not backwards compatible with older accessories. This interface supports the following capabilities:
• Enhanced Audio Functionality – This unique technology enables communication between the radio and Motorola enhanced accessories to optimize audio performance. It enables more consistent audio levels between accessory types, so that users of different microphones will sound more consistent and interoperate more effectively. It also optimizes audio quality performance for a given accessory type, employing DSP (digital signal processing) technology to best match the radio’s audio signals to the capabilities of the accessory.
• USB Capability – The MOTOTRBO accessory and peripherals interface incorporates standard Universal Serial Bus (USB) capability, enabling IP connectivity via standard USB ports with Personal Computers and other peripherals via a Motorola-supplied cable. This interface supports radio programming capabilities with no RIB box required, from the front
(microphone port) connection. It also supports third party applications by enabling interfaces for IP data service, telemetry services, and text messaging and location tracking; refer to
“Third Party Application Partner Program” on page 88 of this document for more details on
the Third Party Application Partner Program.
• Improved Connection – The MOTOTRBO microphone connection employs a rugged “twist and lock” mechanism for greater durability and connection strength.
3.1.2.2.8 Rear Accessory and Peripherals Interface
The MOTOTRBO mobile radio also supports an improved rear panel accessory and peripherals interface. It supports the following capabilities:
• USB Capability – The MOTOTRBO accessory and peripherals interface incorporates standard Universal Serial Bus (USB) capability, enabling IP connectivity via standard USB ports with Personal Computers and other peripherals via a Motorola-supplied cable. This interface supports radio programming capabilities with no RIB box required. This interface also supports third party applications by enabling interfaces for IP data service, telemetry
services, and text messaging and location tracking; refer to “Third Party Application Partner
Program” on page 88 of this document for more details on the Third Party Application
Partner Program.
• Core peripherals – The MOTOTRBO accessory and peripherals interface also includes core functionality for audio input and output, PTT, monitor, receive unsquelch, channel steering, and other general purpose input-output (GPIO) functions. This enables interface with dispatch and telemetry applications and other traditional radio system applications.
November, 2008
106 System Components and Topologies
3.1.3 Data Applications
3.2 System Topologies
The primary element in the design of any private two-way radio communications system is the networking of a fleet of field radios (portable and mobile radios). To set up such a system, the following questions should be asked :
• How many system users require a field radio?
• Which system users need to communicate with each other?
• Where are system users transmitting and receiving from when communicating with other system users?
This information becomes the basis in determining the extent of the required system coverage area, and the creation of its topologies. This information and the desired feature set determines decisions on the system’s topology.
3.2.1 Direct Mode
If, within the customer’s required coverage area, any system user can directly communicate with all of the other system users with just the output power of the transmitter in their portable or mobile radio, then a Direct Mode system can be used. Thus, a Direct Mode system is a system where no infrastructure is required to successfully communicate with all of the system's field radios. All field radios are within range of each other at all times. A single frequency is assigned to all field radios to serve as a half-duplex channel.
The radios are not limited to one direct mode frequency. They can be programmed to have different frequencies, which are selectable with the channel selector knob.
Direct mode does not need over-the-air hang time for voice calls (See “Repeater” on page 93.).
The radio has an internal call (“talk back”) timer. The channel access method used before the call timer expires is impolite, since the radio is still a member of an active call. This is independent of the Channel Access selection for call initiation (polite or impolite).
November, 2008
System Components and Topologies
3.2.1.1 Digital MOTOTRBO Radios in Direct Mode
TX = f
1
RX = f
1 f
1 digital f
1
TX = f
1
RX = f
1
107
MOTOTRBO SU
(digital mode)
MOTOTRBO SU
(digital mode)
Figure 3-5 MOTOTRBO Radios (in digital mode) In Direct Mode
In direct mode configuration, a single frequency is assigned to all radios to communicate with each other. Since there is no repeater designating a slotting structure, there is no time slot synchronization. Therefore, only one voice conversation or data transaction can occur at a time on that channel. In digital direct mode, the radios support all three methods of voice transmission: group calls, private calls and all calls. They can also support all command and control messaging like Call Alert, Radio Check, Radio Enable/Disable, Remote Monitor and Emergency.
3.2.1.1.1 Text Messaging in Direct Mode
TX = f
1
RX = f
1 f
1 digital f
1
TX = f
1
RX = f
1
TM TM
MOTOTRBO SU
(digital mode)
MOTOTRBO SU
(digital mode)
Figure 3-6 MOTOTRBO Radios (in digital mode) Text Messaging In Direct Mode
In direct mode, the MOTOTRBO radios are capable of sending text messages to other radios.
Radio to radio text messaging is accomplished by a text messaging application that is built into the radio. From the front keypad, the radio user can select the target radio, and type a text message.
November, 2008
108 System Components and Topologies
In order for the text message to be sent successfully to the target radio, both radios need to be on the same frequency. Similar to voice, if multiple direct mode frequencies are being used, the user must choose the channel his target is on before sending his text message. The radios do not have to be on the same group.
Text messaging and the previously discussed voice services operate on the same frequency.
Since data operates in a polite manner, the radio avoids transmitting text messages while any voice service is active. If operating with only field radios, text messages are limited to radio to radio communications.
Text messages can also be sent from radio to radio using a PC attached to the radio. A softwarebased text messaging client will be installed on the PC. These configurations are commonly used in vehicles or on desktops that do not have LAN connections. Since they can run on AC power or off the in-vehicle battery, mobile radios are usually used for these applications, though a portable can also be used. Note that the radio can be configured to route incoming text messages to itself or to the PC, but not both.
Text Message Client
(TMC)
TX = f
1
RX = f
1
TM
USB f
1 digital f
1
TM
TX = f
1
RX = f
1
USB
Text Message Client
(TMC)
Mobile PC
Terminal
MOTOTRBO SU
(digital mode)
MOTOTRBO SU
(digital mode)
Mobile PC
Terminal
Figure 3-7 MOTOTRBO Radios (in digital mode) Text Messaging In Multiple Direct Mode
3.2.1.1.2 Telemetry Commands in Direct Mode
Below are some basic telemetry configurations, each with a quick description.
TX = f
RX = f
1
1 f
1 digital f
1
TX = f
RX = f
1
1
GPIO
(Output)
Telemetry Device
(Customer Provided)
MOTOTRBO SU
(digital mode)
MOTOTRBO SU
(digital mode)
Figure 3-8 Send Telemetry Command from MOTOTRBO Radio to Another MOTOTRBO Radio to Toggle an Output Pin
November, 2008
System Components and Topologies 109
In the first basic configuration, a portable radio is programmed with a button that sends a preconfigured telemetry command over the air to toggle a mobile radio’s output GPIO pin. The GPIO pin is connected to external hardware that detects this change at the GPIO pin, and turns on a light. This configuration can be extended to other applications like remotely opening door locks, turning on pumps, or switching on sprinklers. Another application might be to combine the voice from the radio’s external audio lines, a relay closure, and a public announcement system to remotely make announcements over the intercom from your portable radio.
TX = f
1
RX = f
1 f
1 digital f
1
TX = f
1
RX = f
1
“Door Open”
GPIO
(Input)
Telemetry Device
(Customer Provided)
MOTOTRBO SU
(digital mode)
MOTOTRBO SU
(digital mode)
Figure 3-9 Send Telemetry Message from MOTOTRBO Radio to Another MOTOTRBO Radio when Input
Pin State Changes
This second basic configuration is a mobile that is connected to a customer supplied external telemetry hardware, which sends an event to one of the mobile’s GPIO pins when it detects that a particular door has been opened. Upon detecting the GPIO pin as active, it sends a pre-configured
Text Status Message to a particular portable radio. The portable radio displays “Door Opened” to the user as a popup alert. This basic configuration can be used at remote locations to detect a variety of sensors such as water levels, door and window intrusions, or even motion sensors.
Combining the first and second configuration, the user can create complex control systems that initiates a large door to close, and then announces when the door physically closes.
TX = f
RX = f
1
1 f
1 digital f
1
TX = f
RX = f
1
1
GPIO
(Output)
Telemetry Device
(Customer Provided)
MOTOTRBO SU
(digital mode)
GPIO
(Input)
Telemetry Device
(Customer Provided)
MOTOTRBO SU
(digital mode)
Figure 3-10 Send Telemetry Command to Toggle an Output Pin from MOTOTRBO Radio to Another
MOTOTRBO Radio when Input Pin State Changes
November, 2008
110 System Components and Topologies
The third basic configuration is a mobile that is connected to customer supplied external telemetry hardware, which sends an event to one of the mobile’s GPIO pins when it detects that a particular door has been opened. Upon detecting the GPIO pin as active, it sends a telemetry toggle command to another mobile radio. This mobile radio is configured to toggle an output pin, which is connected to telemetry hardware that sounds an alarm. Similar to the other configurations, this method can be extended to a myriad of other solutions such as only opening doors when other doors have been closed, or turning on water pumps when water levels reach a particular level.
This configuration can be used automate the environment of two remote locations. The possibilities are only limited by the designer’s imagination.
3.2.1.1.3 Server-Based Data Applications in Direct Mode
MOTOTRBO also supports server based data applications in direct mode. This configuration consists of a PC (referred to as the Application Server) running the server software connected to the radio infrastructure via a mobile radio (or control station). The mobile radio is usually AC powered. The mobile is configured as a control station, therefore it routes all data to the
Application Server. Since this mobile is the radio gateway to the server, it is configured to transmit and receive on a single channel. The control station is programmed with a known radio ID, so the field radios know how to contact the server. The server and the control station (connected via
USB) must be located in the center of the customer’s coverage area since all field radios are expected to communicate with it. There can only be one Application Server per system.
One key service offered by the server based configuration is radio presence notification. The
Presence Notifier is required to reside on the Application Server. The purpose of the Presence
Notifier is to track whether field radios are currently present on the system. Upon power-up or channel change, the MOTOTRBO radio transmits a registration message to the control station connected to the Application Server, where the Presence Notifier resides. The Presence Notifier then informs other data applications that the radio is available to receive and transmit data messages.
Typically, location applications require a server-based configuration and the Presence Notifier to operate. The Location Server application is installed on the Application Server machine with the
Presence Notifier. When a radio registers with the Presence Notifier, it informs the Location Server that this radio is now on the system. The Location Server then sends out a service availability message through the control station to the radio informing it how often to send in periodic updates, and what to do if an emergency is initiated.
November, 2008
System Components and Topologies 111
Location Dispatch applications request a radio’s location information from the Location Server application, and display the radio’s location on a map. A Location Dispatch application can reside on the Application Server as well. The diagram below depicts this configuration.
Presence Notifier
Location Server
Location
Dispatch
TX = f
1
RX = f
1
USB f
1 digital f
1
GPS
TX = f
1
RX = f
1
MOTOTRBO
Control Station
(digital mode)
MOTOTRBO SU
(digital mode)
Application Server
Figure 3-11 MOTOTRBO Radios In Digital Direct Mode with Location Server and Local Location Client
Text Messaging also uses a server based configuration. Similar to the Location Server, the Text
Message Server application is installed on the Application Server machine with the Presence
Notifier. When a radio registers with the Presence Notifier, it informs the Text Message Server that the radio is now on the system. The Text Message Server then sends out a service availability message through the control station to the radio informing it how it can communicate with the Text
Message Server. Text Message Dispatch applications communicate with the Text Message
Server in order to send and receive messages to and from the radio network via the connected control station. A Text Message Dispatch application can reside on the Application Server as well.
As previously described, radios can send text messages to each other without communicating through the Text Message Server. But in order to send and receive text messages to Text
Message Dispatchers, the Text Message Server configuration is required. The diagram below depicts this configuration. This configuration also works with external text message applications connected to the field radios.
Presence Notifier
Text Message
Server
Text Message
Dispatch
Location Server
Location
Dispatch
TX = f
1
RX = f
1
USB
MOTOTRBO
Control Station
(digital mode) f
1 digital f
1
TM
GPS
TX = f
1
RX = f
1
USB
MOTOTRBO SU
(digital mode)
Text Message Client
(TMC)
Mobile PC
Terminal
Application Server
Figure 3-12 MOTOTRBO Radios In Digital Direct Mode with Text Message Server, Location Server and
Local Dispatchers
November, 2008
112 System Components and Topologies
This configuration can be expanded by locating up to four Text Message Dispatchers and four
Location Dispatchers throughout the customer’s Enterprise Network. Up to four installations of each application can be located anywhere on the customer’s LAN, as long as they can communicate with the Application Server. The Dispatcher installation on the Application Server counts as one of the instances of the dispatch software. The diagram below shows two instances of each application. One is on the Application Server and one remote. The applications can reside on the same remote machine, if desired.
Internet
(E-mail)
NETWORK
L o c a t i o n
D i s p a t c h
P C T e r m i n a l
T e x t M e s s a g e
D i s p a t c h
N E T W O R K
C u s t o m e r
E n t e r p r i s e
N e t w o r k
( C E N )
N E T W O R K
P r e s e n c e N o t i f i e r
T e x t M e s s a g e
S e r v e r
T e x t M e s s a g e
D i s p a t c h
L o c a t i o n S e r v e r
L o c a t i o n
D i s p a t c h
A p p il c a t i o n S e r v e r
T X f
1
R X = f
1
U S B
(
=
C
M o d i
O n g
T t r
O T R B o l S t a
O t i o n i t a l m o d e ) d i g f
1 f i t
1 a l
T M
G P S
T X =
R X =
M O T O T R B O S U
( d i g i t a l m o d e ) f
1 f
1
N E T W O R K
P C T e r m i n a l
Figure 3-13 MOTOTRBO Radios In Digital Direct Mode Server Based Configuration with Remote
Dispatchers
Another Text Message service that is only available in a server based configuration is the ability to receive and send text messages to external e-mail addresses. This allows PCs or pagers and cell phones that are text message capable on the system to send e-mail messages. In order for the
Text Message Server to communicate with the outside world, the Application Server must have access to the internet. When a radio sends a text message to a Text Message Dispatcher, and it is identified as an external e-mail address in the Text Message Server, the Text Message Server will forward the text message to the designated e-mail address.
The Text Message Server forwards incoming e-mails in a similar fashion.
3.2.1.1.4 Multi-Channel Server-Based Data Applications in Direct Mode
For larger systems that have multiple direct mode frequencies, the Application Server can be connected to up to four control stations. Each control station is configured to communicate on the specified channel and acts as the data gateway for that channel.
November, 2008
System Components and Topologies 113
Presence registration works in the same manner with this configuration as it does with the single channel configuration. When a radio powers up or changes channels, it sends in a registration to the Presence Notifier via the control station, which then informs the applications of the radio’s presence. Each control station has the same radio ID, therefore the field radios transmit their messages to this radio ID regardless of which channel they are on.
Because the field radios are located on different channels, a Multi-Channel Device Driver (MCDD) is required to track the location of each radio, so outbound data from the Application Server can be routed to the appropriate channel. The MCDD is a small piece of software installed on the
Application Server. Each control station is handled like a different network interface to the
Application Server. When the MCDD sees a registration, it updates the PC’s routing table so that any data traffic for that radio is routed out the correct network interface, and therefore through the correct control station and over the correct channel. This allows data applications to simply transmit a data message to the radio, and the MCDD takes care of the routing to the correct channel.
Any channel, that supports data and needs to communicate to the Application Server, needs a dedicated control station.
Internet
(E-mail)
NETWORK
L o c a t i o n
D i s p a t c h
P C T e r m i n a l
T e x t M e s s a g e
D i s p a t c h
N E T W O R K
N E T W O R K
C u s t o m e r
E n t e r p r i s e
N e t w o r k
( C E N )
N E T W O R K
P r e s e n c e N o t i f i e r
T e x t M e s s a g e
S e r v e r
T e x t M e s s a g e
D i s p a t c h
L o c a t i o n S e r v e r
L o c a t i o n
D i s p a t c h
A p p il c a t i o n S e r v e r
P C T e r m i n a l
T
R
X
X
=
= f f
1
1
U S B
M O T O T R B
C o n t r o l
O
S t a t i o n
( d i g i t a l m o d e )
T
R
X
X
=
= f f
2
2 f
1 d i g i t a l f
1 f
2 d i g i t a l f
2
G P S
T X
R X
=
= f
1 f
1
M O T O T R B O S U
( d i g i t a l m o d e )
T M
G P S
T X
R X
=
= f
2 f
2
U S B
M O T O T R B
C o n t r o l
O
S t a t i o n
( d i g i t a l m o d e )
M O T O T R B O S U
( d i g i t a l m o d e )
Figure 3-14 MOTOTRBO Radios in Two Channel Digital Direct Mode Server-Based Configuration with
Remote Dispatchers
November, 2008
114 System Components and Topologies
3.2.1.1.5 GPS Revert in Direct Mode
With the addition of the GPS Revert feature, it is now possible to transmit Location Update
messages on channels other than the Selected Channel (See “GPS Revert Channel” on page 36
for configuration information). The diagram in Figure 3-15 illustrates this concept in its simplest
form while operating in direct mode. In this example, Channel f1 is the Selected Channel and
Channel f2 is the GPS Revert Channel. Communications such as presence, location requests
(application server to SU), text and voice occur on the Selected Channel, while all location responses (SU to application server) including location updates occur on the GPS Revert
Channel. Therefore, a minimum of 2 control stations are required to support GPS Revert.
MCDD
Presence Notifier
Location Server
Application Server
TX=f
1
RX=f
1 f
1
Presence f
1
Location Request f
1
GPS
TM
SELETED
TX=f
1
RX=f
1
GPS REVERT
TX=f
2
RX=f
2
USB
Response
MOTOTRBO
Control Station
(digital mode)
Location
MOTOTRBO SU
(digital mode)
Location f
1
Request f
1
TX=f
2
RX=f
2
USB
MOTOTRBO
Control Station
(digital mode)
Location Response f
2
GPS
TM
SELETED
TX=f
1
RX=f
1
GPS REVERT
TX=f
2
RX=f
2
MOTOTRBO SU
(digital mode)
Figure 3-15 MOTOTRBO Radios in Two Channel Direct Mode GPS Revert Configuration
Under a typical scenario, the SU is powered on, and then registers on the Selected Channel with the Presence Notifier and the Location Server. The SU receives a Periodic Location Request and an Emergency Location Request from the Location Server on the Selected Channel. This Periodic
Location Request instructs the SU to send location updates at a specific rate, while the Emergency
Location Request instructs the SU to send a single Emergency Location Update when an emergency is initiated.
The SU spends the most time on the Selected Channel. The SU only switches to the GPS Revert
Channel when a Location Update needs to be transmitted. Since voice transmissions have priority over data transmissions, when the SU is involved in a call on the Selected Channel, the Location
Update is queued until after the call is completed. In order to minimize the amount of time spent away from the Selected Channel while on the GPS Revert Channel, the SU will not attempt to qualify traffic on the GPS Revert Channel. Therefore, all voice, data, and control messages destined to a SU should never be transmitted on the GPS Revert Channel, as they will not reach their destination.
November, 2008
System Components and Topologies 115
The example in Figure 3-15 illustrates only one GPS Revert Channel. However, depending on the
GPS data load, more than one GPS Revert Channel may be needed. For example, a single large group that generates significant Location Update traffic must be sub-divided across several GPS
Revert Channels. Each GPS Revert Channel requires a control station, which must be connected to the Application Server PC. The maximum number of control stations that can be connected to the PC is four.
3.2.1.1.6 Summary of Features in Digital Direct Mode
The following features are supported in digital direct mode:
Digital MOTOTRBO Radios in Direct Mode
Voice
Features
Signaling
Features
Emergency Handling Data Calls
Other
Features
Group Call
Private Call
All Call
PTT ID and
Aliasing
Radio Inhibit
Emergency Alarm
Emergency Alarm with
Call
Remote Monitor Emergency Alarm with
Voice to Follow
Radio Check Emergency Revert
Text
Messaging
Location
Tracking
Telemetry
Scan
Priority Scan
Time-out Timer
Third-Party
(ADP)
Applications
GPS Revert
Polite to All channel access
Call Alert Polite to Own
System channel access
Impolite channel access
*See “Scan Considerations” on page 41 for more information on the different scan modes
supported by different topologies.
November, 2008
116 System Components and Topologies
3.2.1.2 Interoperability between Analog MOTOTRBO Radios and Analog
Radios in Direct Mode
TX = f
1
RX = f
1 f
1 analog f
1
TX = f
1
RX = f
1
Legacy
Analog SU
MOTOTRBO SU
(analog mode)
Figure 3-16 Legacy Analog Radios and MOTOTRBO Radios (in analog mode) in Direct Mode
November, 2008
System Components and Topologies 117
MOTOTRBO radios support analog mode as well. In order for the MOTOTRBO radio to communicate with an analog radio, it must be programmed for analog mode, as well as programmed with the same frequency and parameters (for example, PL and DPL) as the analog radio. While in analog mode, the MOTOTRBO radio supports most standard analog features including a subset of MDC signaling features. While in analog direct mode, the MOTOTRBO radios does not support any of the digital features.
3.2.1.2.1 Summary of Features in Analog Direct Mode
All features listed in “Analog Features” on page 78 are supported in analog direct mode.
3.2.1.3 Interoperability between Digital MOTOTRBO Radios, Mixed Mode
MOTOTRBO Radios, and Analog Radios in Direct Mode
TX = f
1
RX = f
1 f
1 analog f
1
TX = f
1
RX = f
1
TX = f
2
RX = f
2 f
2 digital f
2
TX = f
2
RX = f
2
Legacy
Analog SU
MOTOTRBO SU*
(analog mode & digital mode)
MOTOTRBO SU
(digital mode)
* changed via mode choice
Figure 3-17 Legacy Analog and MOTOTRBO Analog and Digital Radios in Direct Mode
In this configuration, a MOTOTRBO subscriber is programmed to talk to an analog radio as well as a MOTOTRBO radio that is programmed for digital only.
In order for the MOTOTRBO radio to communicate with the analog radio, it must be programmed for analog mode, as well as programmed with the same frequency and parameters (for example
PL and DPL) as the analog radio.
When in the digital mode, the MOTOTRBO subscriber has all of the digital features that are available in digital direct mode. However, the MOTOTRBO radio user has to manually switch from digital mode to analog mode to communicate with the two groups.
Alternatively, the MOTOTRBO radio user can program the radio to scan between the analog and digital channels to ensure a call is not missed. This can be done from the keypad of the radio or
through the CPS. Please see “Scan” on page 39 and “Scan Considerations” on page 41 to learn
more about scan.
November, 2008
118 System Components and Topologies
3.2.2 Repeater Mode
There are a few reasons why a customer may require a repeater in their system. The first is, if the required coverage area is large, they may require strategically located high power repeaters in order to cover all of their operating space. Even if their required coverage area is small, due to geographical limitations such as mountains, valleys or man made obstructions, they may still need multiple high power repeaters to reach all the coverage areas. They also may need the extra bandwidth a repeater offers. One channel may not be able to support a large number of users; therefore additional channels may be required.
In many of these cases, the insertion of a MOTOTRBO repeater can alleviate the problems with minimum additional cost. Such a repeater is transparent to field radio communications. They just select the required channel using their channel selector, and continue their normal communications. However, as in most conventional systems, if the repeater coverage does not overlap, the user needs to know his location, and switch to the other channel when required.
Even just having one MOTOTRBO repeater provides increased user capacity. The digital repeater operates in TDMA which essentially divides one channel into two virtual channels in digital mode; therefore the user capacity doubles. Without the repeater, this TDMA synchronization is not possible. The repeater utilizes embedded signaling to inform the field radios of the status of each channel (time slot). It informs the field radios of each channel’s busy/idle status, the type of traffic, and even the source and destination information.
Another advantage during digital operation is error detection and correction. The further a transmission travels, the more interference it encounters, and inevitably more errors are introduced. The receiving MOTOTRBO radio, operating in digital mode, utilizes built-in error detection and correction algorithms, native to the protocol, to correct these problems. The
MOTOTRBO repeater uses the same algorithms to correct the errors prior to retransmission, thus repairing any errors that occur on the uplink; it then transmits the repaired signal on the downlink.
This greatly increases the reliability and audio quality in the system, which increases the customer’s coverage area.
In digital mode, the repeater only retransmits digital signals from radios configured with the same system identifier. This aids in preventing co-system interference. The repeater does not block transmissions of radios within its own system.
As previously described, the repeater utilizes embedded signaling to announce the current status of each channel. It is up to the radios in the field to interpret these signals, and grant or deny their user’s request for transmission. Therefore, when a user or a group of users utilizes a channel (time slot), the repeater announces that the channel is being used and who is using it. Only radios that are part of that group are allowed to transmit. The repeater additionally allows a short duration of reserved time after a transmission. This allows other users in the group to respond to the originator. This reserved hang time greatly increases the continuity of calls, because new calls cannot start until the previous call ends. Without this feature, users may experience delays in responses (that is, between transmissions of calls), due to other calls taking over the channel inbetween their transmissions.
After this reserved hang time, the repeater stays active for a short period of time, and offers an opportunity for any user on the system to transmit or start a new call. If no user transmits for a duration of time, the repeater stops transmitting. When the next radio transmission occurs, the repeater starts repeating again.
November, 2008
System Components and Topologies 119
Most of the basic MOTOTRBO voice and data services work the same in repeater mode as they do in direct mode. The customer will only notice the increased performance and coverage.
3.2.2.1 Digital MOTOTRBO Radios in Repeater Mode
TX = f
1
RX = f
2
Slot = 1 f
2 s
1 f
1 dig ital s
1 f
1 s 1 dig ita l f 2 s 1
TX = f
1
RX = f
2
Slot = 1
TX = f
2
RX = f
1
MOTOTRBO SU
(digital mode)
MOTOTRBO SU
(digital mode)
TX = f
1
RX = f
2
Slot = 2 f 1 s 2 dig ita l f
2 s 2
Slot 1
Slot 2
MOTOTRBO
Digital Repeater* f dig f
1 s
2 ital
2 s
2
TX = f
1
RX = f
2
Slot = 2
MOTOTRBO SU
(digital mode)
MOTOTRBO SU
(digital mode)
Figure 3-18 MOTOTRBO Digital Radios on MOTOTRBO Two-Slot Digital Repeater
In digital mode, a repeater uses one frequency pair (1-transmit, 1-receive) to support the two logical channels. As mentioned before, this is done by using TDMA technology to divide the physical channel into two time slots. In order to access the repeater, the radio user selects the physical and logical channel using the channel selector. Hence, when operating in repeater mode, the field radios cannot dynamically choose a time slot. Each of the channel selector positions is programmed for a particular digital frequency and time slot. The end user sees, in effect, each time slot as a different conventional channel. Radio groups can be further segmented within the time slot by assigning different group IDs to each group. Groups on different time slots cannot communicate with each other.
Synchronization is the key to a MOTOTRBO repeater system. It is the role of the repeater to keep this synchronization. When accessed, the repeater begins transmitting idle messages as well as identifying the time slot structure. The radios synchronize to the transmissions from the repeater.
When a radio transmits on its time slot, the radio pulses its transmissions in 30ms increments. This allows for simultaneous conversation to occur on the other time slot. While the first radio is pulsed on, the other radio is pulsed off. The repeater receives these two pulsed transmissions, combines them and transmits them in the correct order in one continuous transmission.
November, 2008
120 System Components and Topologies
Repeater operation supports all three methods of voice transmission: group calls, private calls and all calls. They can also fully support all command and control messaging like Call Alert, Radio
Check, Radio Enable/Disable, Remote Monitor and Emergency.
3.2.2.1.1 Text Messaging in Repeater Mode
TX = f
1
RX = f
2
Slot = 1
TM dig f
2 s
1 f
1 s ital
1 f 1 s 1 dig ita l f 2 s 1
TM
TX = f
1
RX = f
2
Slot = 1
MOTOTRBO SU
(digital mode)
TX = f
1
RX = f
2
Slot = 2
TM
TX = f
2
RX = f
1
MOTOTRBO SU
(digital mode) f 1 s 2 ita l dig f 2 s 2
Slot 1
Slot 2
MOTOTRBO
Digital Repeater f f
1 s dig ital
2
2 s
2
TM
TX = f
1
RX = f
2
Slot = 2
MOTOTRBO SU
(digital mode)
MOTOTRBO SU
(digital mode)
Figure 3-19 MOTOTRBO Radios in Digital Two-Slot Digital Repeater Mode with Built-In Text Messaging
In repeater mode, the MOTOTRBO radios are capable of sending text messages to other radios.
Radio to radio text messaging is accomplished by a text messaging application that is built into the radio. From the front keypad, the radio user can select the target radio, and type a text message.
In order for the text message to be sent successfully to the target radio, both radios need to be on the same channel and time slot. Similar to voice, if multiple direct mode frequencies are being used, the user must choose the channel his target is on before sending his text message. The radios do not have to be on the same group.
Text messaging and the previously discussed voice services operate on the same channel and time slot. Since data operates in a polite manner, the radio avoids transmitting text messages while any voice service is active. If operating with only field radios, text messages are limited to radio to radio communications.
November, 2008
System Components and Topologies 121
Text messages can also be sent from radio to radio using a PC attached to the radio. A softwarebased text messaging client will be installed on the PC. These configurations are commonly used in vehicles or on desktops that do not have LAN connections. Since they can run on AC power or off the in-vehicle battery, mobile radios are usually used for these applications, though a portable can also be used. Note that the radio can be configured to route incoming text messages to itself or to the PC, but not both.
Text Message Client
(TMC)
TX = f
1
RX = f
2
Slot = 1
TM
USB
Mobile PC
Terminal
MOTOTRBO SU
(digital mode) dig f
1 s
1 ital f
2 s
1
TX = f
2
RX = f
1 f 1 s 1 ita l dig f 2 s 1
TM
TX = f
1
RX = f
2
Slot = 1
USB
Text Message Client
(TMC)
MOTOTRBO SU
(digital mode)
Mobile PC
Terminal
Text Message Client
(TMC)
TX = f
1
RX = f
2
Slot = 2
TM
USB f
1 s 2 dig ita f
2 l s 2
Slot 1
Slot 2
MOTOTRBO
Digital Repeater f dig f
1 s
2 ital
2 s
2
TM
TX = f
1
RX = f
2
Slot = 2
USB
Text Message Client
(TMC)
Mobile PC
Terminal
MOTOTRBO SU
(digital mode)
MOTOTRBO SU
(digital mode)
Mobile PC
Terminal
Figure 3-20 MOTOTRBO Radios in Digital Two-Slot Digital Repeater Mode with Text Messaging
November, 2008
122 System Components and Topologies
3.2.2.1.2 Telemetry Commands in Repeater Mode
Below are some basic telemetry configurations using both time slots of a repeater. A description of each follows.
TX = f
1
RX = f
2
Slot = 1
GPIO
(Output)
Telemetry Device
(Customer Provided)
MOTOTRBO SU
(digital mode) f
2 f
1 dig ital s s
1
1
TX = f
2
RX = f
1
TX = f
1
RX = f
2
Slot = 1 f 1 s 1 dig ita f 2 l s 1
GPIO
(Input)
MOTOTRBO SU
(digital mode)
Telemetry Device
(Customer Provided)
TX = f
1
RX = f
2
Slot = 2
“Door Open” f 1 s 2 dig ita f 2 s l
2
Slot 1
Slot 2
MOTOTRBO
Digital Repeater f f
1 dig ital s
2
2 s
2
TX = f
1
RX = f
2
Slot = 2
GPIO
(Input)
Telemetry Device
(Customer Provided)
MOTOTRBO SU
(digital mode)
MOTOTRBO SU
(digital mode)
(Output)
Telemetry Device
(Customer Provided)
Figure 3-21 MOTOTRBO Radios in Digital Two-Slot Digital Repeater Mode with Telemetry Functions
In the first basic configuration a portable radio is programmed with a button (shown by the pointing finger above) that sends a preconfigured telemetry command over the air on the second time slot to toggle a mobile radio’s output GPIO pin. The GPIO pin is connected to external hardware that detects the closure and turns on a light (shown by a light bulb above). This configuration can be extended to such things as remotely opening door locks, turning on pumps, or switching on sprinklers. Another application might be to combine the voice from the radio’s external audio lines, a relay closure, and a public announcement system to remotely make announcements over the intercom from your portable radio.
This second basic configuration is a mobile configured on the second time slot, connected to customer supplied external telemetry hardware (shown by the door icon in lower right corner), detects a closure that signifies a door has been opened. Upon detecting the GPIO pin as active, it sends a pre-configured Text Status Message to a particular portable radio. The portable radio displays “Door Opened” to the user as a popup alert. This basic configuration can be used at remote locations to detect a variety of sensors such as water levels, door and window intrusions, or even motion sensors. Combining the first and second configuration, the user can create complex control systems that initiates a large door to close, and then announces when the door physically closes.
November, 2008
System Components and Topologies 123
The third basic configuration is a mobile configured on the first time slot, connected to customer supplied external telemetry hardware, detecting a closure that signifies a door has been opened
(shown by door in upper right corner). Upon detecting the GPIO pin as active, it sends a telemetry toggle command to another mobile radio on the first time slot. This mobile radio is configured to toggle an output pin which is connected to telemetry hardware that sounds an alarm (shown by alarm on upper left corner). Similar to the other configurations, this method can be extended to a myriad of other solutions such as only opening doors when other doors have been closed or turning on water pumps when water levels reach a particular level. This configuration can be used automate the environment of two remote locations together. The possibilities are only limited by the designer’s imagination.
3.2.2.1.3 Server Based Data Applications in Repeater Mode
MOTOTRBO also supports server based data applications in repeater mode. This configuration consists of a PC (referred to as the Application Server) running the server software connected to the radio infrastructure via a mobile radio. The mobile radio is usually AC powered. The mobile is configured as a control station, therefore it routes all data to the Application Server. Since this mobile is the radio gateway to the server, it should be configured to transmit and receive on a single channel (frequency and time slot). The control station is programmed with a known radio ID so the field radios know how to contact the server. The server and the control station (connected via USB) must be located in an area that is in good coverage of the repeater it is communicating with. If there are multiple repeaters covering a large geographical area, the Application Server’s control stations must be located in good coverage of each repeater. This is important since it is common for the overlap between repeaters to be small and often only in low signal strength areas.
There can only be one Application Server per system.
One key service offered by the server based configuration is radio presence notification. The
Presence Notifier is required to reside on the Application Server. The purpose of the Presence
Notifier is to track whether field radios are currently present on the system. Upon power-up or channel change, the MOTOTRBO radio transmits a registration message to the control station connected to the Application Server, where the Presence Notifier resides. The Presence Notifier then informs other data applications that the radio is available to receive and transmit data messages.
Each frequency and time slot that needs to communicate with the Application Server needs to have its own control stations. The Application Server can be connected to up to 4 control stations.
Each control station is configured to communicate on the specified frequency and time slot and acts as the data gateway for that channel. Therefore a MOTOTRBO system can support server based data on up to two repeaters, each with two time slots.
When a radio powers up or changes channels it sends in a registration to the Presence Notifier via the control station on its frequency and time slot, which in turn informs the applications of the radio’s presence. Each control station has the same radio ID, therefore the field radios transmit their messages to the same radio ID regardless of which frequency and time slot they are on.
Because the field radios are located on different time slots, there needs to be a method to track the location of each radio so that outbound data from the Application Server can be routed to the appropriate time slot. This is the purpose of the Multi-Channel Device Driver (or MCDD). The
MCDD is a small piece of software installed on the Application Server. Its purpose is to keep track of which interface each radio is currently located on. Each control station is handled like a different network interface to the Application Server. When the MCDD sees a registration from a radio, it updates the PC’s routing table so that any data traffic targeted towards that radio will be routed out the correct network interface, therefore out the correct control station and over the air frequency
November, 2008
124 System Components and Topologies and time slot. This allows data applications to simply transmit a data message to the radio and the
MCDD takes care of the routing to the correct frequency and time slot.
Any channel that supports data and needs to communicate to the Application Server needs a dedicated control station. Below is a diagram of this configuration.
T X = f
1
R X = f
2
S l o t = 1 f f
1 dig ital s
1
2 s
1 f 1 s 1 digi tal f 2 s 1
T M
G P S
T
R
X
X
=
= f f
1
2
S l o t = 1
U S B
P r e s e n c e N o t i f i e r
T e x t M e s s a g e
S e r v e r
T e x t M e s s a g e
D i s p a t c h
L o c a t i o n S e r v e r
L o c a t i o n
D i s p a t c h
A p p il c a t i o n S e r v e r
C
M O o n
T O t r o l
T R B O
S t a t i o n
( d i g i t a l m o d e )
T X = f
1
R X = f
2
S l o t = 2 f 1 s 2 dig ita f 2 l s 2
T X = f
2
R X = f
1
S l o t 1
S l o t 2
D i
M g i
O t
T a l
O T R B
R e p e
O a t e r f f
1 dig ital s
2
2 s
2
M O T O T R B O S U
( d i g i t a l m o d e )
T M
G P S
T
R
X
S l
X o t
=
=
= f f
1
2
2
U S B
C
M O T O T R B O o n t r o l S t a t i o n
( d i g i t a l m o d e )
M O T O T R B O S U
( d i g i t a l m o d e )
Figure 3-22 MOTOTRBO Radios in Digital Two-Slot Digital Repeater Mode with a Server-Based
Configuration
Typically, location applications require a server-based configuration and the Presence Notifier to operate. The Location Server application can be installed on the Application Server machine with the Presence Notifier. When a radio registers with the Presence Notifier, it informs the Location
Server that this radio is now on the system. The Location Server then sends out a service availability message through the control station to the radio informing it how often to send in its periodic updates and what to do if an emergency is initiated.
Location Dispatch applications request a radio’s location information from the Location Server application, and display the radio’s location on a map. A Location Dispatch application can reside on the Application Server as well.
Text messaging also uses a server based configuration. Similar to the Location Server, the Text
Message Server application can be installed on the Application Server machine with the Presence
Notifier. When a radio registers with the Presence Notifier, it informs the Text Message Server that the radio is now on the system. The Text Message Server then sends out a service availability message through the control station to the radio informing it how it can communicate with the Text
Message Server. Text Message Dispatch applications communicate with the Text Message
Server in order to send and receive messages to and from the radio network via the connected
November, 2008
System Components and Topologies 125 control station. Like the Location Dispatch, the Text Message Dispatch application can reside on the Application Server too.
As previously described, radios can send text messages to each other without communicating through the Text Message Server. But in order to send and receive text messages to Text
Message Dispatchers, the Text Message Server configuration is required. This configuration also works with external text message applications connected to the field radios.
This configuration can be expanded by locating up to four Text Message Dispatchers and four
Location Dispatchers throughout the customer’s Enterprise Network. Up to four installations of each application can be located anywhere on the customer’s LAN, as long as they can communicate with the Application Server. The Dispatcher installations on the Application Server counts as one of the instances of the dispatch software. The diagram below shows 2 instances of each application. One is on the Application Server and one remote. The applications can reside on the same remote machine, if desired.
T
R
X
X =
S l o t
= f
1 f
2
= 1
T X = f
1
R X =
S l o t f
2
= 1
Internet
(E-mail)
NETWORK
U S B digit f
1 s
1 al f
2 s
1 f
1 s 1 dig ita l f 2 s 1 T M
G P S
T X = f
2
R X = f
1
L o c a t i o n
D i s p a t c h
P C T e r m i n a l
T e x t M e s s a g e
D i s p a t c h
N E T W O R K C u s t o m e r
E n t e r p r i s e
N e t w o r k
( C E N )
N E T W O R K
P r e s e n c e N o t i f i e r
T e x t M e s s a g e
S e r v e r
T e x t M e s s a g e
D i s p a t c h
L o c a t i o n S e r v e r
L o c a t i o n
D i s p a t c h
A p p l i c a t i o n S e r v e r
N E T W O R K
M
C o
O T n t
O r o
T l
R B
S t a t
O i o n
( d i g i t a l m o d e )
S l o t 1
U S B
T X = f
1
R X = f
2
S l o t = 2
S l o t 2 f 1 s 2 dig ita l f 2 s 2
M
D i g i t
O T a
O T R l R e
B O p e a t e r f dig f
1 s
2 ital
2 s
2
M O T O T R B O S U
( d i g i t a l m o d e )
T
R
X
X
=
= f f
1
2
S l o t = 2
T M
G P S
M O
C o n t
T O r o l
T R
S t
B a t i
O o n
( d i g i t a l m o d e )
M O T
( d i
O g i t
T R B O S U a l m o d e )
P C T e r m i n a l
Figure 3-23 MOTOTRBO Radios in Digital Two-Slot Digital Repeater Mode with a Server-Based
Configuration and Remote Dispatchers
Another Text Message service that is only available in a server based configuration is the ability to receive and send text messages to external e-mail addresses. This allows PCs or pagers and cell phones that are text message capable on the system to send e-mail messages. In order for the
Text Message Server to communicate with the outside world, the Application Server must have access to the internet. When a radio sends a text message to a Text Message Dispatcher, and it is identified as an external e-mail address in the Text Message Server, the Text Message Server will forward the text message to the designated e-mail address. It requires access to the internet in order to send the message.
The Text Message Server also forwards incoming e-mails in a similar fashion.
November, 2008
126 System Components and Topologies
On the following page is an example of a server based configuration that supports four data capable time slots with local and remote dispatchers. Note that any mix of external and internal radio Text Message Clients are supported on each channel.
November, 2008
System Components and Topologies s d s f 1 s
2 d ig ita l f 2 s
2 f 1 s
1 d ig ita l f 2 s
1 s d s s d s f 3 s
2 d ig ita l f 4 s
2 f 3 s
1 d ig ita l f 4 s
1 s d s
Driver
DD)
Device
(MC annel Ch Multi-
127
November, 2008
128 System Components and Topologies
3.2.2.1.4 GPS Revert in Repeater Mode
With the addition of the GPS Revert feature, it is now possible to transmit Location Update
messages on channels other than the Selected Channel (See “GPS Revert Channel” on page 36
for configuration information). The diagram in Figure 3-25 illustrates this concept in its simplest
form while operating in repeater mode. In this example, channels f1s1 and f2s1 compose the
Selected Channel frequency pair and channels f1s2 and f2s2 compose the GPS Revert Channel frequency pair. Communications such a presence, location requests (application server to SU), text and voice occur on the Selected Channel, while all location responses (SU to application server) including location updates occur on the GPS Revert Channel. Therefore, a minimum of 2 control stations are required to support GPS Revert.
MCDD
TX=f
RX=f
Slot 1
1
2
USB
MOTOTRBO
Control Station
(digital mode)
Location f
S
1
Request f
S
1 f
S
1
TX=f
2
RX=f
1 f
S
2
1
Presence
/V oice f
S
1
/T ext
1
SELETED
TX=f
1
RX=f
2
Slot 1
Location
Response f
S
1
2
Location
Location
GPS
Request
TM f
S
2
1
MOTOTRBO SU
(digital mode)
GPS REVERT
TX=f
1
RX=f
2
Slot 2
Presence Notifier
Location Server
Application Server
TX=f
1
RX=f
2
Slot 2
USB
MOTOTRBO
Control Station
(digital mode)
Request
Location
Response f
S
2
2
Slot 1 f
Location
1
Slot 2
MOTOTRBO
Digital Repeater
Response f
S
2
Presence f
/V oice
S
1 f
S
1
/T ext
GPS
SELETED
TX=f
1
RX=f
2
Slot 1
TM
GPS REVERT
TX=f
1
RX=f
2
Slot 2
MOTOTRBO SU
(digital mode)
Figure 3-25 MOTOTRBO Radios in Two-Slot Digital Repeater Mode with GPS Revert Configuration
Under a typical scenario, the SU is powered on, and then registers on the Selected Channel with the Presence Notifier and the Location Server. The SU receives a Periodic Location Request and an Emergency Location Request from the Location Server on the Selected Channel. This Periodic
Location Request instructs the SU to send location updates at a specific rate, while the Emergency
Location Request instructs the SU to send a single Emergency Location Update when an emergency is initiated.
The SU spends the most time on the Selected Channel. The SU only switches to the GPS Revert
Channel when a Location Update needs to be transmitted. Since voice transmissions have priority over data transmissions, when the SU is involved in a call on the Selected Channel, the Location
Update is queued until after the call is completed. In order to minimize the amount of time spent away from the Selected Channel while on the GPS Revert Channel, the SU will not attempt to qualify traffic on the GPS Revert Channel. Therefore, all voice, data, and control messages destined to a SU should never be transmitted on the GPS Revert Channel, as they will not reach their destination.
November, 2008
System Components and Topologies 129
The example in Figure 3-25 illustrates only one GPS Revert Channel. However, depending on the
GPS data load, more than one GPS Revert Channel may be needed. For example, a single large group that generates significant Location Update traffic must be sub-divided across several GPS
Revert Channels. Each GPS Revert Channel requires a control station, which must be connected to the Application Server PC. The maximum number of control stations that can be connected to the PC is four.
3.2.2.1.5 Summary of Features in Digital Repeater Mode
The following features are supported in digital repeater mode:
Digital MOTOTRBO Radios in Repeater Mode
Voice
Features
Signaling
Features
Emergency
Handling
Data Calls
Other
Features
Group Call PTT ID and
Aliasing
Emergency Alarm Text
Messaging
Two channels
(slot 1 and slot 2) per repeater frequency pair
Scan*
-
Private Call
All Call
Radio Inhibit
Radio Check
Emergency Alarm with Call
Remote Monitor Emergency Alarm with Voice to
Follow
Emergency Revert
Location
Tracking
Telemetry
Third-Party
(ADP)
Applications
Time-out Timer
Polite to All system access
Call Alert GPS Revert Polite to Own
System channel access
Impolite channel access
*See “Scan Considerations” on page 41 for more information on the different scan modes
supported by different topologies.
November, 2008
130 System Components and Topologies
3.2.2.2 Analog MOTOTRBO Radios in Repeater Mode
TX = f
2
RX = f
1
TX = f
1
RX = f
2 f
1 analog f
2 f
1 analog f
2
TX = f
1
RX = f
2
Legacy
Analog SU
Legacy
Analog Repeater
MOTOTRBO SU
(analog mode)
Figure 3-26 MOTOTRBO Analog and Legacy Analog Radios on Legacy Analog Repeater
MOTOTRBO radios supports analog repeater mode as well. In order for the MOTOTRBO radio to communicate with the existing analog repeater, it must be programmed for analog mode as well as programmed with the same frequency and other options (PL, DPL, etc.) as the existing analog repeater. While in analog mode, the MOTOTRBO radio supports most standard analog features including a subset of MDC signaling features. While in analog repeater mode, the MOTOTRBO radios will not support any of the digital features.
TX = f
2
RX = f
1
TX = f
RX = f
1
2 f
1 analog f
2 f
1 analog f
2
TX = f
RX = f
1
2
Legacy
Analog SU
MOTOTRBO
Analog Repeater
MOTOTRBO SU
(analog mode)
Figure 3-27 MOTOTRBO Analog and Legacy Analog Radios on MOTOTRBO Analog Repeater
If required, the MOTOTRBO repeater can be programmed to operate in analog repeater mode.
When operating in this mode, it interoperates with the existing analog radios as well as the
MOTOTRBO radios operating in analog mode. It is important to note that the MOTOTRBO repeater can only be configured to operate in analog mode or digital mode. It does not do both at the same time.
The MOTOTRBO radio can be configured with both analog and digital repeater channels. The user can select between the analog and digital repeaters via the Channel Selector Knob.
November, 2008
System Components and Topologies 131
TX = f
3
RX = f
4
Alternatively, the MOTOTRBO radio user can program his radio to scan between the analog and digital channels to ensure that they do not miss a call. The programming can be done from the keypad of the radio or through CPS. Details of scan will be discussed in the following sections.
Below is an example configuration of a mixed repeater mode system.
f
3 analog f
4
TX = f
4
RX = f
3 f
3 analog f
4
TX = f
3
RX = f
4
TX = f
1
RX = f
2
Slot = 1 f dig
2 s
1 f
1 s ital
1 f 1 s 1 dig ita l f 2 s 1
TX = f
1
RX = f
2
Slot = 1
TX = f
5
RX = f
6
Legacy
Analog SU
Legacy
Analog Repeater
MOTOTRBO SU
(analog mode & digital mode)*
TX = f
2
RX = f
1 f
5 analog f
6
TX = f
6
RX = f
5 f
5 analog f
6
TX = f
5
RX = f
6
TX = f
1
RX = f
2
Slot = 2 f 1 s 2 dig ita l f 2 s 2
Slot 1
Slot 2
MOTOTRBO
Digital Repeater* f dig f
1 s
2 ital
2 s
2
MOTOTRBO SU
(digital mode)
TX = f
RX = f
1
2
Slot = 2
Legacy
Analog SU
MOTOTRBO
Analog Repeater
MOTOTRBO SU
(analog mode & digital mode)*
MOTOTRBO SU
(digital mode)
* changed via mode choice
Figure 3-28 MOTOTRBO Digital Radios on a Two-Slot MOTOTRBO Digital Repeater with Analog Legacy
Repeater Support
3.2.2.2.1 Summary of Features in Repeater Mode
All features listed in “Analog Features” on page 78 are supported in analog repeater mode.
3.2.3 IP Site Connect Mode
In IP Site Connect mode, repeaters across dispersed locations exchange voice, data, and control packets over an IPv4-based back-end network. The potential applications of this mode include:
• Connecting two or more dispersed locations for day-to-day communications.
For example, a customer’s manufacturing facility and a distribution facility across towns can be connected using MOTOTRBO repeaters in IP Site Connect mode.
• Building a larger or more effective RF coverage area.
For example, multiple repeaters installed in an amusement park or a high-rise building can be connected to provide a contiguous area of RF coverage. The need for multiple repeaters may stem from any combination of geography (distance or topographical interference problems) and in-building or cross-building RF penetration issues.
November, 2008
132 System Components and Topologies
• Broadcasting announcements to all sites.
This is useful in case of emergency or special events.
• Connecting repeaters operating in different RF bands.
For example, repeaters operating in UHF (UHF-1 and UHF-2) or VHF frequencies can be combined so that voice or data from one system flows into another.
• Connecting to IP-based applications.
IP Site Connect mode allows the customers to connect to third-party IP-based dispatch consoles, or call logging and recording applications, or routing calls to/from IP-based phones.
3.2.3.1 Topologies of IP Site Connect System
3.2.3.1.1 Wide Area System with Centralized Data Application Server
This basic topology (as shown in Figure 3-29) is a single wide area system that consists of multiple
single repeater systems operating in digital mode and zero or more application servers connected over a back-end network that supports IPv4, where:
• A repeater system consists of a fixed digital repeater, digital radios (with or without an accessory or a data terminal), and two conventional physical channels. Only one of the repeaters, which is called the Master, has an additional role in the IP Site Connect mode.
This additional role involves brokering of UDP/IP address and states of repeaters.
• A radio uses one slot of a pair of frequencies (i.e. inbound and outbound) to communicate with its repeater. The pair of frequencies and/or the color code used by repeaters are not necessarily the same. Their frequencies may be in different frequency bands.The geographically adjacent repeaters have different frequencies. Two repeaters with the same frequency must be separated by a suitable distance to minimize interference and must use unique color codes.
• An Application Server is a PC-like equipment where one or more application runs. An application can be a data application such as a Location Server, Text Message Server or a voice application such as a Console. An Application Server is connected to one or two
Control Stations, and these Control Stations are connected over-the-air to a repeater. If the configuration has more than one Control Station, then the Application Server should have the MCDD software installed. A third party application can reside on an Application Server and since the Application Server is connected to Control Stations (one per logical channel), the application is not required to implement any third party API that partially emulates the behavior of a MOTOTRBO repeater and radio.
• The back-end network can be a dedicated network or most probably an internet provided by an Internet Service Provider (ISP). ISPs provide a range of technologies such as dial-up,
DSL (typically, ADSL), cable modem, broadband wireless access, ISDN, Frame Relay,
Satellite Internet access, etc. The back-end network cannot be based on a dial-up connection (due to small bandwidth) or Satellite Internet access (due to large delay). The IP
Site Connect configuration does not require an ISP to provide a non-varying (static) IPv4 address except for the Master repeater. A repeater can be behind a firewall and/or a router and/or a NAT. A repeater has USB and Ethernet network interfaces. The USB is used for
November, 2008
System Components and Topologies 133
Site 1
Presence Notifier
Text Message
Server
Text Message
Dispatch
Location Server
Location
Dispatch
Application Server connecting a local PC and Ethernet is used for connecting to the back-end network of an IP
Site Connect system.
Network
Site 2
TX = f
4
RX = f
3
WAC1
WAC2
MOTOTRBO
Digital Repeater f
TX = f
3
RX = f
4
Slot = 1
TM
GPS f 4 s 1 dig ita f 3 l s 1
MOTOTRBO SU
(digital mode ) f
4 s digit al
3 s
2
2
TM
GPS
TX = f
3
RX = f
4
Slot = 2
MOTOTRBO SU
(digital mode )
* WAC = Wide Area Channel
*TM = Text Messaging
USB
TX = f
1
RX = f
2
Slot = 1
MOTOTRBO
Control Station
(digital mode )
TX = f
1
RX = f
2
Slot = 2
TX = f
2
RX = f
1 digit f
1 s al f
2 s
1
1 f 1 s 2 dig ita l f
2 s 2
WAC1
WAC2
MOTOTRBO
Digital Repeater
( MASTER )
MOTOTRBO
Control Station
(digital mode )
Site 3
TX = f
6
RX = f
5
WAC1
WAC2
MOTOTRBO
Digital Repeater f
TX = f
5
RX = f
6
Slot = 1
TM
GPS f 6 s 1 dig ita l f 5 s 1
MOTOTRBO SU
(digital mode ) digit f
6 s al
5 s
2
2
TM
GPS
TX = f
5
RX = f
6
Slot = 2
MOTOTRBO SU
(digital mode )
Figure 3-29 Wide Area System with Centralized Data Application Server
There may be an application known as RDAC-IP running on a host PC connected to the back-end network of an IP Site Connect system. The application displays the status of repeaters and allows its user to control some of the parameters of a repeater. The host PC maintains its link with the
Master and other repeaters using the same protocols as other repeaters in an IP Site Connect system. Note that there may be a local RDAC application running on a host PC connected to a repeater through RNDIS-USB interface. Also, analog, and local area only repeaters can be connected to wide area system so that they may be managed by the RDAC application.
In digital mode, MOTOTRBO offers two logical channels. The configuration above shows both the channels acting as wide area channels. This means that when a call starts at one of the logical channels of a repeater, that repeater sends the call to all the other repeaters and they repeat the call on their corresponding logical channel. Since calls are not repeated on both logical channels, a radio on a logical channel cannot participate in a voice call on the other logical channel or logical channels of other IP Site Connect systems unless scan is utilized. Note that scanning cannot be enabled while roaming. Radio to radio data messages are not repeated on both slots either, although it is possible to support one Application Server to serve multiple wide area channels. The
November, 2008
134 System Components and Topologies
Application Server interfaces with the wide area channels in the same way as it interfaces with the local area channels. This is described in section 3.2.2.1.3 “Server Based Data Applications in
Repeater Mode”.
3.2.3.1.2 Wide and Local Area Systems with Distributed Data Application
Servers
It is possible that one of the logical wide area channels of the repeaters is configured for local communication only. In this case, each site has its own logical channel for local communication.
This is useful in case a customer need a significant load of local communication. This configuration offloads the local communication from the wide area channel.
The following figure shows an example of such configuration in which one of the logical channels
(say, slot 2) is used in IP Site Connect mode (wide area) and the other (slot 1) is used in digital repeater mode (local area). The calls originating on slot 1 are not sent to other repeaters. A customer should use slot 1 for local groups (i.e. groups whose members are expected to be present in the coverage area of the repeater); and slot 2 for groups whose members are distributed over the coverage area of multiple repeaters.
Site 1 Site 3
TX = f
2
RX = f
1
TX = f
6
RX = f
5
Presence Notifier
Text Message
Server
Text Message
Dispatch
Location Server
Location
Dispatch
Application Server
Site 2
Presence Notifier
Text Message
Server
Text Message
Dispatch
Location Server
Location
Dispatch
Application Server
USB
TX = f 1
RX = f
2
Slot = 1
MOTOTRBO
Control Station
(digital mode ) f 1 s 1 dig ita f 2 l s 1
WAC1
LC1
MOTOTRBO
Digital Repeater
( MASTER )
TX = f
4
RX = f
3
TX = f 3
RX = f
4
Slot = 2
USB
MOTOTRBO
Control Station
(digital mode ) digit f
3 s
2 al f
4 s
2
WAC1
LC2
MOTOTRBO
Digital Repeater
Network
WAC1
LC3
MOTOTRBO
Digital Repeater
TX = f 5
RX = f
6
Slot = 2 f 5 s 2 di git al f 6 s 2
MOTOTRBO
Control Station
(digital mode )
USB
TX = f
8
RX = f
7
LC4
LC5
TX = f
7
RX = f
8
Slot = 1 f 7 s 1 di git al f 8 s 1
MOTOTRBO
Control Station
(digital mode ) f dig f
8 ital
7 s
2 s
2
TX = f
RX = f
7
8
Slot = 2
MOTOTRBO
Digital Repeater
MOTOTRBO
Control Station
(digital mode )
Presence Notifier
Text Message
Server
Text Message
Dispatch
Location Server
Location
Dispatch
Application Server
* WAC = Wide Area Channel
*LC = Local Channel
*TM = Text Messaging
Figure 3-30 Wide and Local Area System with Distributed Data Application Servers
The data messages sent over local channel 1 are not delivered to the Application Server 1 and therefore, if required, each geographical location should have their own Application Server with their own Presence Notifier. When a radio manually roams (i.e. changes dial positions) between a local area channel and a wide area channel, the radio registers with its respective Presence
Notifier. To facilitate this, the radio ID of the control stations should be configured to be the same.
If a customer requires more local capacity at a location then it is possible to add more repeaters working in Single-Site configuration and all the local slots of all the repeaters can share the same
Application Server. In that case, the radios on the local channel will not be able to communicate with the wide area channels’ Application Server.
November, 2008
System Components and Topologies 135
3.2.3.1.3 Multiple Wide Area Systems with Centralized Data Application
Server
If a customer requires more wide area capacity, then it is possible to add another set of repeaters working in IP Site Connect mode. It is possible for the repeaters to share the same Application
Server. This is shown in the figure below. In this case, the repeaters at a location may share the same link to the back-end network. The bandwidth required for communication through the back-
Site 1
Presence Notifier
Text Message
Server
Text Message
Dispatch
Location Server
Location
Dispatch
Application Server
* WAC = Wide Area Channel
USB
TX = f
1
RX = f
2
Slot = 1
MOTOTRBO
Control Station
(digital mode )
TX = f
1
RX = f
2
Slot = 2
TX = f
2
RX = f
1 digit f
1 s al f
2 s
1
1 f 1 s 2 igi tal f 2 s 2
WAC1
WAC2
MOTOTRBO
Digital Repeater
( MASTER )
USB
USB
MOTOTRBO
Control Station
(digital mode )
TX = f
3
RX = f
4
Slot = 1
MOTOTRBO
Control Station
(digital mode )
USB
TX = f
3
RX = f
4
Slot = 2
MOTOTRBO
Control Station
(digital mode )
TX = f
4
RX = f
3 f digit f
3 s al
4 s
1
1 f 3 s 2 dig ita l f 4 s 2
WAC3
WAC4
MOTOTRBO
Digital Repeater
( MASTER )
Network
TX = f
6
RX = f
5
WAC1
WAC2
MOTOTRBO
Digital Repeater
TX = f
10
RX = f
9
WAC1
WAC2
MOTOTRBO
Digital Repeater
Site 2
TX = f
8
RX = f
7
WAC3
WAC4
MOTOTRBO
Digital Repeater
Site 3
TX = f
12
RX = f
11
WAC3
WAC4
MOTOTRBO
Digital Repeater
Figure 3-31 Multiple Wide Area Systems with Centralized Data Application Server
If a customer requires more wide area capacity for location data, then it is possible to use one or more wide area channels as GPS revert channels. The GPS revert channel behavior of radios in
IP Site Connect mode is the same as the radios behavior in digital repeater mode with the
exception that the GPS is sent unconfirmed on a wide area channel. See “GPS Revert in Repeater
November, 2008
136 System Components and Topologies
3.2.3.1.4 Network Topologies for IP Site Connect
The IP Site Connect topologies described in the previous sections can reside on a range of backend network configurations and technologies. Logical connections between the wide area channels can all reside on the same physical network. The actual network topology chosen will most likely be driven by the repeater’s physical location and the network connectivity available at that location. The Network Topologies can be broken up into two basic configurations:
• Local Area Network Configuration
• Wide Area Network Configuration
But note that most network topologies will be a combination of both Local and Wide Area network configurations. Each individual configuration will be described and discussed.
Note that the same network configurations can be used for Digital or Analog Repeaters, Enabled or Disabled Repeaters, Wide Area or Local Area Repeaters, RDAC-IP, or any other third party device that utilizes the IP Site Connect link establishment protocol.
3.2.3.1.4.1Local Area Network (LAN) Configuration
Customers that have high capacity network connectivity throughout their organization will most likely have a desire to utilize their existing network for wide area connectivity. IP Site Connect supports the following technologies:
• Private LANs
• Corporate LANs
• Private Wireless Systems (e.g. Motorola’s Canopy 1 or Point-to-Point (PTP) systems 2
Exact configurations of Local Area Networks can vary greatly. As long as the devices are on the same network, or have access to other networks through an internal router or NAT configurations, the IP Site Connect system will operate correctly. It is also assumed that in these local configurations that bandwidth is not an issue. Nevertheless, it is important for the system installer to understand the bandwidth that each IP Site Connect devices require in order to operate
optimally. See “Network Bandwidth Considerations” on page 162.
The diagram below shows a simple diagram of IP Site Connect devices located at different sites connected through a local area network. Note that in this drawing the IP Site Connect devices could be in one or more Wide Area Systems (i.e. more than one Master), could contain local area channels or even be an analog repeater, a disabled repeater, or RDAC IP application.
1.
For more information about Canopy, see http://www.motorola.com/Business/US-EN/
Business+Product+and+Services/Wireless+Broadband+Networks/Point-to-Multipoint+Networks
2.
For more information about PTP, see http://www.motorola.com/Business/US-EN/
Business+Product+and+Services/Wireless+Broadband+Networks/Point-to-Point
November, 2008
System Components and Topologies 137
Only the repeaters acting as Masters will require a local static IPv4 address. The other IP Site
Connect devices will utilize this local static IPv4 address to establish their link with the wide area system.
IP Site
Connect
Device
IP Site
Connect
Device
IP Site
Connect
Device
Network
Local Area
Network
IP Site
Connect
Device
IP Site
Connect
Device
IP Site
Connect
Device
Figure 3-32 IP Site Connect devices connected through Local Area Network
3.2.3.1.4.2Wide Area Network Configuration
The largest benefit of IP Site Connect is the ability to connect sites over public Internet Service
Provider (ISP) links as well as private high speed connections. ISPs provide a range of technologies with varying bandwidth. IP Site Connect supports the following technologies (as long as the requirements listed in the back-end Network Considerations section are met):
• Private T1
• DSL (typically ADSL)
• Cable Modem
• Broadband Wireless Access (e.g. Public Canopy provided by WISPs [Wireless Internet
Service Providers])
• ISDN
• Frame Relay
November, 2008
138 System Components and Topologies
IP Site Connect does not support dial-up connections (due to small bandwidth) or Satellite Internet access (due to large delay). When utilizing public internet connections, it is important that the system installer understand the bandwidth and delay that each IP Site Connect device requires in order to operate optimally. They must also understand the details (bandwidth and delay) of the network link at each site and between sites. For example, if connecting sites have long distances between them, the delay of the entire link needs to be considered. Spanning continents connected via Satellite may introduce unacceptable delay. But, if the continents are connected via fiber optic there may not be any issues.
Also keep in mind that because traffic from one repeater is sent to every repeater, the required bandwidth of the ISP link at one site is a function of the amount of other repeaters in the system.
Adding a repeater will increase the required bandwidth at all sites. See “Network Bandwidth
A repeater can be (and is suggested to be) behind a router and/or a NAT and/or a firewall.
Although not required, it is highly suggested in order to protect against the undesired solicitations common over the public internet. Although IP Site Connect will work through most off-the-shelf devices, the following two router/NAT/firewalls have been validated and are therefore suggested for use.
• D-Link - EBR-2310
• CISCO - PIX 501
As previously described, peer-to-peer communications over the network can be optionally authenticated and are also encrypted end-to-end if enabled in the radios. If this is not considered sufficient for a particular customer, IP Site Connect supports the ability to work through a Secure
VPN (Virtual Private Network). Secure VPN is not a function of the IP Site Connect device but rather of the router. It is important to note that VPN does add the need for additional bandwidth and may introduce additional delay. This should be taken into consideration in bandwidth planning. The
following Secure VPN router has been validated and is therefore suggested for use. See “Network
Bandwidth Considerations” on page 162.
• Linksys 4 Port Gigabit Security Router with VPN: Model RVS4000.
Only the repeaters acting as Masters require a publicly accessible static IPv4 address from the
Internet Service Provider. The other IP Site Connect devices utilize this publicly accessible static
IPv4 address to establish their link with the wide area system. In addition, the router/NAT/firewall connected to the Master require some configuration (open port) so that unsolicited messages from other repeaters can reach the Master repeater.
The diagram below shows a simple diagram of IP Site Connect devices located at different sites connected through a wide area network.
November, 2008
System Components and Topologies 139
Note that in this drawing the IP Site Connect devices could be in one or more Wide Area Systems
(i.e. more than one Master), could contain local area channels or even be an analog repeater, a disabled repeater, or RDAC IP application.
IP Site
Connect
Device
IP Site
Connect
Device
IP Site
Connect
Device
Network
Router
Wide Area
Network
Router
Router
Router
IP Site
Connect
Device
IP Site
Connect
Device
IP Site
Connect
Device
Figure 3-33 IP Site Connect Devices connected through Wide Area Network
3.2.3.1.5 Wide and Local Area Network Configuration
Most network topologies are a combination of both Local and Wide Area network configurations.
For example, there may be a need to link two or more sites with existing local networks together over a public ISP, or maybe link one or more remote mountain RF site into a corporate network.
When doing this, there are a few extra precautions to consider that are not covered in the previous sections.
The number of IP Site Connect devices connected together behind a single wide area connection
(i.e. behind one router) can have a large effect on the required bandwidth of the wide area link.
The bandwidth requirements of a wide area link are the summation of the bandwidth requirements of all IP devices behind the router. In other words, if there are three IP Site Connect devices utilizing a single ISP link, it must have enough bandwidth to support all three. Recall that the traffic from one repeater is sent to every repeater; therefore the required bandwidth of the ISP link at one
November, 2008
140 System Components and Topologies site is a function of the amount of other sites in the system. Adding a repeater at one site increases the required bandwidth at all sites.
Similar to the Wide Area Network configurations, the repeaters acting as the Master will require a publicly accessible static IPv4 address from the Internet Service Provider. The other IP Site
Connect devices utilize this publicly accessible static IPv4 address to establish their link with the wide area system, not a local IPv4 address. This is true even for the IP Site Connect devices that are located on the same Local Area Network as the Master.
Again, similar to the Wide Area Network configurations, the router/NAT/firewall connected to the
Master require some configuration (open port) so that unsolicited messages from other repeaters can reach the Master repeater.
To support the ability for the IP Site Connect devices to communicate to other devices on its LAN using the WAN IPv4 address, the routers on those WANs must support a feature referred to as
“hair-pinning”. Hair-pinning is returning a message in the direction it came from as a way for it to reach its final destination. This is per the router standard RFC 4787.
The diagram below shows a simple diagram of IP Site Connect devices located at different sites connected through a mix of local and wide area networks. Note that in this drawing the IP Site
Connect devices could be in one or more Wide Area Systems (i.e. more than one Master), could contain local area channels or even be an analog repeater, a disabled repeater, or RDAC IP application.
IP Site
Connect
Device
The number of IP Site Connect Devices located behind a single router will have an effect on the required bandwidth of the WAN connection.
Router
Network
IP Site
Connect
Device
IP Site
Connect
Device
Local Area
Network
Router
Wide Area
Network
Router
Local Area
Network
IP Site
Connect
Device
IP Site
Connect
Device
Router
“Router” = Firewall, NAT, or Router
IP Site
Connect
Device
Figure 3-34 IP Site Connect Devices connected through Local Area and Wide Area Network
November, 2008
System Components and Topologies 141
The following chapter discusses some of the considerations to take while designing a
MOTOTRBO system. It focuses more on how the user uses the system, and the configuration needed to support it. Although a basic system topology may already have been chosen, the next chapter helps dig deeper into how the end user utilizes the system, and therefore gives additional ideas on how it should be configured.
3.2.3.1.6 Summary of Features in IP Site Connect Mode
The following features are supported in IP Site Connect mode:
Digital MOTOTRBO Radios in IP Site Connect Mode
Voice
Features
Signaling
Features
Emergency
Handling
Data Calls Other Features
Group Call
Private
Call
PTT ID and
Aliasing
Radio Inhibit
Emergency
Alarm
Emergency
Alarm and Call
Text
Messaging
Location
Tracking
Third-Party
(ADP)
Applications
GPS Revert
Per Site
Two Wide Area
Channels (slot
1 and slot 2)
Mix of Wide
Area and Local
Area Channels
Scan*
-
-
All Call Remote
Monitor
Radio Check
Call Alert -
Emergency
Alarm with Voice to Follow
Emergency
Revert Per Site
Telemetry
Polite to All
System
Access
Polite to Own
System
Channel
Access
Impolite
Channel
Access
*See “Scan Considerations” on page 41 for more information on the different scan
modes supported by different topologies.
-
Remote
Diagnosis and
Control
Roaming
Wide Area
Coverage
Time-out Timer
Enhanced
Privacy
November, 2008
142
Notes
System Components and Topologies
November, 2008
System Design Considerations
SECTION 4 SYSTEM DESIGN CONSIDERATIONS
143
4.1 Purpose
This section describes various system configurations readers need to know before deciding how to best support the needs and usage of their customers. It explains the usage supported on a single repeater system, as a guideline for design. It then identifies the customer needs that need to be considered when optimizing system performance. It continues to cover various other considerations that may need to be addressed during the design phase.
Please note that all data application modules contained in this system planner are depictions of typical third party data application modules and have been included simply to illustrate certain
MOTOTRBO application enabling features.
4.2 Migration Plans
System Migration is the process of moving from one operating platform to another. The following sections elaborate system migration from an analog two-way radio platform to a digital two- way radio platform.
4.2.1 Pre-Deployment System Integration
Where applicable, the dealer should perform system assembly, configuration, adjustment, and brief testing of the MOTOTRBO system. Each component contains documentation necessary for system installation and optimization. The benefits of staging a system in a controlled environment include:
• Equipment accountability in preparation for system assembly
• System assembly and programming in a controlled test environment
• Documentation of programming information
• Fabrication of cables and connectors
• Test of complete functionality and initial level-setting for system optimization
4.2.2 Analog to Digital Preparation and Migration
This section details migration strategies which involve gradually replacing existing analog radios with MOTOTRBO radios.
To migrate a system with a single repeater channel, radio users are encouraged to use
MOTOTRBO radios in digital direct mode. This will give them an opportunity to familiarize themselves with the MOTOTRBO digital feature set, while communicating with legacy analog radios through the legacy analog repeater. If the analog system does not use any PL/DPL encoding, then analog radios will hear noise caused by digital radio transmissions communicating in direct mode.
Over time, as the number of MOTOTRBO radios increases, a cut-over day is pre-determined. On that day, the legacy analog repeater will be replaced by a MOTOTRBO digital repeater. Radio
November, 2008
144 System Design Considerations users communicate with each other in talkaround while the new repeater is being installed. Once the MOTOTRBO repeater is operational, MOTOTRBO radio users switch to digital repeater mode, while legacy analog radio users communicate in talkaround.
To migrate a system with two repeater channels, MOTOTRBO radios are programmed with both the current analog channels as well as future digital channels. A recommended approach is to place all the analog channels in one ‘zone’, and all digital channels in another ‘zone’. Analog and digital channels are programmed into the MOTOTRBO radios to allow users to communicate on both repeaters. Scan lists are configured to allow users to monitor both analog and digital voice transmissions.
Both the existing analog repeater and the MOTOTRBO repeater (in digital mode) should be set-up to operate side-by-side. This configuration requires two frequency pairs: one pair for the analog repeater and one pair for the MOTOTRBO repeater. Users gradually migrate over to the
MOTOTRBO repeater (i.e. legacy analog radios are swapped for MOTOTRBO radios). Once every analog radio has been swapped with a MOTOTRBO radio, the legacy analog repeater can be replaced with another MOTOTRBO digital repeater. The system will now be fully digital with two digital repeater channels.
4.2.3 New/Full System Replacement
The new/full system replacement strategy involves replacing all existing equipment with
MOTOTRBO equipment. Typically, a new/full system replacement involves minimal downtime as the analog repeater is replaced immediately with the MOTOTRBO digital repeater. Radio users carry their existing radios as well as MOTOTRBO radios on cut-over day. Initially, users will continue to access the radio system in the same manner as before. Once the analog repeater is removed from the system, the radio users switch to digital direct mode communication using
MOTOTRBO radios. After the MOTOTRBO repeater is installed and becomes operational, radio users switch their MOTOTRBO radios to digital repeater mode.
The new/full system replacement relies on the MOTOTRBO equipment being properly programmed and tested before being deployed.
4.3 Frequency Licensing
4.3.1 Acquiring 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 will operate 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. For MOTOTRBO systems, the Emissions Designators are
• Data only: 7K60FXD
November, 2008
System Design Considerations 145
• Voice and Data: 7K60FXE
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.
• 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 ground 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.
4.3.2 Converting Existing 12.5/25kHz Licenses
The process for converting 25kHz to 12.5kHz varies between regions. It is recommended to 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 US, the following are general guidelines for frequency licenses:
• For existing 12.5kHz license(s), the user needs to file an update to the emission designators indicating 7K60FXE (for voice) and 7K60FXD (for data) for all applicable frequencies.
• If the user has existing 25kHz licenses(s), they need to file an update to the emission designators to include 7K60FXE (for voice) and 7K60FXD (for data) for all applicable frequencies. Typically, the user will then be allowed to transmit a 12.5kHz signal bandwidth at the same center frequency as the original 25kHz license. Please note that it is not a straightforward process to convert an existing 25kHz license into a pair of 12.5kHz
channels. Users are generally NOT allowed to split their 25kHz channel into two 12.5kHz
sub-channels that would operate off center from the original license and adjacent to one another.
November, 2008
146 System Design Considerations
4.3.3 Repeater Continuous Wave Identification (CWID)
The repeater can be configured to transmit the CWID if required by the region. The CWID is also known as the Base Station ID. The CWID is an analog transmission of the station in Morse code that takes place every 15 minutes. This identification, as well as the transmit interval, can be configured in the repeater using the CPS.
4.4 Digital Repeater Loading
The designer is able to choose the number of channels required to support his customer’s expected traffic after understanding how much traffic a single slot (channel) can support. The amount of traffic on a channel is dependent on numerous variables, which are difficult to estimate exactly at design time. Since MOTOTRBO comprises of Voice traffic, Text Messaging traffic,
Location Tracking traffic, Registration and Signaling traffic, previous voice traffic only methods to gauge repeater capacity may not be sufficient. Because this traffic is mostly initiated by the end user, it is difficult to predict how often it occurs. Standard usage profiles of existing customers have been created for voice and data services. These profiles act as a baseline for estimating how much traffic a user creates on a system. If the standard profiles do not match your customer’s expected usage, further estimations based on the trend lines need to be considered. After the system is used, and real life usage is identified, further adjustments may be required.
4.4.1 Assumptions and Precautions
Channel loading analysis involves several assumptions:
• Generalized high-level view of data and voice services interaction represents true interaction.
• An estimated amount of blocking, interference, reliability, and call denials varies with the traffic profile and could change some of the results used.
• An estimated number of radios using the location tracking feature (100%) and the rate of those messages for the high-end traffic profile (once every minute for every mobile) is used.
Given these assumptions, the chart presented can be used to provide customers with a general rule of thumb for levels of user experience expected based on the number of users. In addition, for this analysis, the term “number of users” is used to indicate the number of active/participating users generating traffic, and does not include the number of users who monitor the activity of other radios on the channel.
4.4.2 Voice and Data Traffic Profile
The following table summarizes the standard traffic profiles for voice and data. The three traffic types considered are voice calls (group calls and private calls), data transmitted for location tracking and text messaging. For each traffic type, two levels are set. One, is for the case of a typical low usage or light traffic user, and the other is for a typical high usage or heavy traffic user.
The voice and text messaging profiles are derived using assumed typical behaviors.
These profiles act as a baseline for estimating how much traffic a user creates on a system. If these standard profiles do not match your customer’s expected usage, further estimations based on the trend lines need to be considered. Further, this is the profile of how all users on a channel
November, 2008
System Design Considerations 147 will act together. It is understandable that not all users will use this profile all the time. These
profiles should be used with Figure 4-1 “Number of Users per Slot versus User Experience” to
estimate the number of users per channel that yield an acceptable user experience.
Profile
Name
Traffic Type Call Description
High Voice
Low Voice
High GPS
Low GPS
High Text
Messaging
Low Text
Messaging
Group Voice Call
Individual Voice
Call
Group Voice Call
Individual Voice
Call
Location Updates
Location Updates
Text Messaging
Text Messaging
10 second call, 2 transmissions per call
20 second call, 4 transmissions per call
10 second call, 2 transmissions per call
20 second call, 4 transmissions per call
.660 seconds per transmission
.660 seconds per transmission
100 characters per message
100 characters per message
Traffic Per User Per Hour
3.0 Calls per User per Hour
90%
10%
90%
1.0 Calls per User per Hour
10%
60 GPS Transmissions per User per Hour i.e. 1 Minute Update Period (Cadence)
6 GPS Transmissions per User per Hour i.e. 10 Minute Update Period (Cadence)
2.5 Text Messages per User per Hour
0.5 Text Messages per User per Hour
4.4.3 Estimating Loading
The following chart indicates the user experience level (the impact on the network) that the
number of active users, using combinations of the defined profiles of “Voice and Data Traffic
Profile” above, will experience.
Each line in the chart has a combination of Voice, GPS, and Text Message at different usage levels. For example, the blue line identified as “Low Usage (Voice, GPS, Text)” represents a channel where each user transmits 1 group call an hour, 2.5 text messages an hour, and has a
GPS Update Period (Cadence) of 10 minutes. If the defined profiles do not exactly match the estimated usage, the reader will need to extrapolate between two trend lines.
There are two levels shown in the graph to describe user experience – good to fair. The good level means that the system is supporting this level well and if the customer is operating in this level the majority of the time, then the system is adequately provisioned. This means that the fair level may be reached for short periods of time as long as the system returns to supporting a lower level of traffic for the majority of the time.
It is advised to avoid operating in the fair level when possible. If the customer experiences issues with reliability and/or call denial, this could indicate that the system is operating in the fair level for longer periods of time. If this occurs, the customer may require additional repeaters to support
November, 2008
148 System Design Considerations their traffic load. A system that operates in the fair level for the majority of the time results in longer wait times and having a significant number of unsuccessful attempts to acquire the channel on the user’s first attempt. These conditions would result in an unsatisfactory level of performance for the end users, even though the system itself is capable of operating in this region.
Fair High Usage (Voice, GPS, Text)
High Voice, High GPS, Low Text
Low Voice, High GPS, Low Text
High Voice, Low GPS, Low Text
High Voice Only
Low Usage (Voice, GPS, Text)
Low Voice Only
Good
0 10 20 30 40
# of Users per Slot
50 60 70
Figure 4-1 Number of Users per Slot versus User Experience
There are trends indicated in the chart that are worth noting. One is the impact in going from a low voice usage traffic environment to a high voice usage traffic environment. The chart shows that a customer using the system for voice services only should be capable of supporting approximately
45 users on the channel if the user traffic falls into the low voice usage traffic profile (one call per user per hour). However, if the customer intends to support a higher level of voice traffic, a single channel should be capable of supporting between 15 and 20 users and still remain in the good user experience level. It will always be difficult to accurately predict a customer’s usage as being either high or low. It is expected that most customers will operate somewhere in between these two profiles. The designer must use knowledge of the customer’s organization and their expected usage to predict where on this chart they will operate. Note that the voice-only lines are a good frame of reference for existing customer with analog voice systems. These trend lines represent those of a voice-only analog system and a voice-only digital system. Understanding what user experience level a customer is currently operating at can help with predicting the new user experience, when adding data services.
Two other trends from the chart are also worth pointing out. The first is that the level of adding data
(low traffic for location tracking and text messaging) does not cause a huge impact to the number of users supported. For example the lines for high voice usage traffic (one with voice only and the other with the addition of low location tracking and text messaging) both show that supporting 15-
20 active users on one channel will keep the system from approaching the stressed level.
Similarly, both curves for the low voice traffic show that 30-35 users could be supported well on a single channel.
Another important note is that these trend lines are associated with a single slot of a MOTOTRBO repeater. Since MOTOTRBO is a two-slot TDMA system, a customer that is upgrading from a traditional FDMA one channel conventional system will have the ability to split users into two slots.
For example, if a high usage voice only customer is currently supporting 30-40 users on a single channel, they are most likely operating in a “fair” or “stressed” environment, and will likely need to expand their system. If they switch to a MOTOTRBO system, they can divide their users into the two available channels. This means a single channel now has only 15-20 users, which would bring
November, 2008
System Design Considerations 149 the customer back to a good user experience level. Subsequently, adding on low usage data services on both channels will cause minimal impact to performance.
4.4.4 Loading Optimization and Configuration Considerations
There are further considerations to take when configuring your MOTOTRBO system to ease the traffic load on a channel. These considerations should always be taken into account, especially if the designer is forced to operate outside of the “good” user experience range, although operating in such a manner is not recommended.
4.4.4.1 Distribution of High Usage Users
It is good design practice to identify and distribute high usage users and groups between slots of a single repeater, or even other repeaters. This keeps the number of users that follow a high usage traffic profile to a minimum per channel. Groups are generally assigned to operate on a particular slot of a repeater. Through discussions with the customer, the designer should identify high usage groups and distribute them over different slots.
Groups and users that are on different slots cannot communicate with each other. They need to manually change their selector knobs to communicate with the users and other groups on the other slot. In most cases, this is not a problem since organizations can usually be broken into at least two groups of users. But in the case where a customer only has one group of users who all need voice communication between each other at all times, then evenly distributing the voice and data load between two channels becomes more complicated.
If there is only one group in a system, its users can all be programmed to operate on a particular slot. Their group calls, private calls, text messages, location updates will all be transmitted on the programmed slot. This is an acceptable configuration, although it leaves the other slot completely unused. If the number of users and their usage grows, the slot may be unable to support their traffic. For example, if a customer has 50 users with voice and GPS usage all on one time slot, their user experience may be poor due to the traffic loading. It is highly recommended that the users in this case be broken into two unique groups of 25, and distributed between the slots.
In the event, that all users could be broken into two unique groups, but are required to maintain voice communication with each other, the solution is to split the same group across the two slots, and enable scan. One half of the group should be assigned to slot 1, and the other half assigned to the same group, but on slot 2. They should use the same group number. This can be done by having two channels with the same frequencies but different slots, and with the same group as the
TX Call Member. All radios should include both (and only) these two channels in their selected scan list. Scan hang time duration should be set to the group call hang time duration in the repeater, which defaults to two seconds. Talkback scan should always be enabled so that users can talkback during the scan hang time. When assigning all users to the same group, the use of scan primarily serves to aggregate the multiple channels into a single logical channel for voice.
Location data will be transmitted out the selected channel when no voice is taking place. Therefore location data will be evenly distributed across two slots. Note that when a voice call occurs, all radios will scan and land on a particular slot. The other slot will be empty at this time since all radios will be monitoring the voice call.
The drawback of this operation, and why it is not generally recommended, is that this configuration essentially cuts the voice capacity of a repeater in half since only one voice call can take place at any given time, although this does allow for data transmission to occur at the same time on the different slots of a repeater. Furthermore, if two radios transmit at the same time on different slots,
November, 2008
150 System Design Considerations some of the radios will scan to one slot, and some will scan to the other slot. It is not possible to predict the distribution since all radios are scanning. Also note, that while scanning, the probability of missing a voice header and entering a call “late entry” increases, therefore missed audio may occur. Because of these drawbacks, it is highly recommended to break users into at least two unique groups and distribute them across slots, and only use this scanning strategy if completely necessary.
4.4.4.2 Minimize Location Periodic Update Rate
The high usage location profile defined assumes that every user on the channel has location capability and uses a 1 minute refresh rate. In actual fact, if every user actually has a 1 minute refresh rate, this increases the traffic loading tremendously. It is recommended that users be configured to use a 10 minute update, and to only increase individual radios to a 1 minute update rate during emergencies or special situations. Although each customer scenario may be different, knowing a user’s location every 10 minutes is usually considered sufficient. If a user reports an emergency, his location update rate can be increased by the location dispatcher for a short period of time. The minimum interval between updates (High Cadence setting) can be set as low as 10 seconds, but with the concerns mentioned above kept in mind.
In order to help visualize the impact of setting the Location Update Period between 1 minute and
10 minutes, the following graph was created using the data presented in Figure 4-1 “Number of
Users per Slot versus User Experience”. The following assumes a specific desired user
experience (approximately mid-way between good and fair). The graph was plotted using the intersection of the Low GPS (10 minute Cadence) and High GPS (1 minute Cadence) lines for
High Voice and Low Voice with the desired user experience design goal.
The chart provides a method to easily set the Location Update Period for a particular number of users on a channel, while keeping their voice usage in mind. The intersection between the number of users and the Location Update Period should always be above the line for the applicable voice usage. For example, if a channel has 10 users, and the users have been determined to be high voice users (3 calls per user per hour), then it is recommended that the Location Update Period be set to 3.5 minutes or higher (longer). Because it is very difficult to determine the true voice usage profile, the administrator/dealer needs to make a judgment call on whether the usage leans towards the High Voice Usage trend or the Low Voice Usage trend.
Although the impact is not substantial, it should be noted that utilizing a high cadence location update rate lowers the overall battery life of the radio since it will be transmitting often.
November, 2008
System Design Considerations 151
10
GOOD
REGION
9
8
7
6
5
4
3
2
1
High Voice Usage ( 3 calls per user per hour)
Low Voice Usage ( 1 call per user per hour)
0 5 10 15 20 25
# of Users per Slot
30
BAD
REGION
35 40 45
*on average, 1 in 5 transmissions will be busied
Figure 4-2 Number of Users versus Location Update Period
The value chosen for the location periodic update rate directly affects scan performance. Most users realize that a radio pauses scanning when transmitting voice, and then resumes scanning once the voice transmission is over. The more voice a user transmits, the less the radio is scanning, which means, its probability of missing traffic increases. This is also true when transmitting data. The more a radio transmits data, the less it is scanning, and therefore the higher the probability of missing traffic. Additionally, if the channel used to transmit the data is busy, it will take longer to deliver the message; therefore the radio's scanning will be further interrupted. This means that the higher the location periodic update rate is for a radio, its scan performance will degrade. This should be kept in mind when using scan with a high cadence location period update.
It is recommended that radios be configured to use a 10 minute update, and that scanning radios should NEVER use a value lower than 2 minutes.
4.4.4.3 Data Application Retry Attempts and Intervals
The interval a data application will retry to send a message and the number of retries it will send if the target does not respond is configurable in the external data applications like Location and Text
Messaging. The following table shows the default values provided:
External Data
Application
Text Messaging
Location Application
Number of
Retries
2
3
Interval Time Period between
Retries
70 seconds
30 seconds
November, 2008
152 System Design Considerations
It is recommended to not change the default values. If this value is lowered too low, messages may become unreliable when a user is on the system, but will free up some bandwidth if the user is not available. Increasing too high until it is past the default will increase the load on a channel although it may increase the probability of delivering a message.
4.4.4.4 Optimize Data Application Outbound Message Rate
Text Message and Location applications both have the ability to set the outbound message rate.
The outbound message rate is defined as the interval in-between subsequent messages sent by the applications to its connected control stations. It is important to note that the application server is connected to up to four channels, and is not aware of which channel is used to route a message.
It is the function of the MCDD to track users, and send messages out the appropriate channel.
Therefore, it is reasonable that the outbound message rate setting be increased to a greater value than the default, if there is more than one channel on a system. The default value for the text message server is 14 messages per minute distributed uniformly. The default value for the
Location Server is 20 messages per minute, distributed uniformly.
For example, if a system only has one data capable channel, and therefore only one control station, the default value of the Outbound Message Rate paces the messages appropriately to not overload the control station or add excessive load to the channel. If there are more than one channel (2 to 4 channels), and the users are distributed fairly evenly over these channels, the
Outbound Message Rate could be increased, since only a portion of the messages will be going to any single channel. It is difficult to predict which channel users will be registered on, and even harder to predict how many messages will be sent to a particular user on a particular channel.
It is recommended that the outbound pacing rates remain as default, though special
considerations for GPS Revert are discussed in “GPS Revert and Loading” on page 152. If they
are increased, and the target radios are not evenly distributed over multiple channels, one channel may experience excess loading. The MOTOTRBO radio can buffer only up to 10 messages. If there is RF congestion on the system, the radio may encounter a situation where its message transmit buffer becomes full. This is due to the radio queuing up messages, because it cannot find an available slot to transmit data. The radio will not be able to process new messages from the application, once its buffer becomes full.
4.4.4.5 GPS Revert and Loading
The GPS Revert feature supports the transmission of voice, control and non-location update data transmissions on the Selected Channel, while off loading Location updates onto one or more GPS
Revert Channels. A primary goal of the feature is to support location updates without degrading features on the Selected Channel. The ultimate performance of the system will depend upon at least two loading factors (1 and 2), while a third loading factor (3) needs to be considered if most radios are powered on in a relatively short period of time. These factors are listed below.
1. The average number of transmissions on the Selected Channel (Voice, Text Messaging, etc.).
2. The average number of transmissions on a GPS Revert Channel.
3. The peak number of transmissions on the Selected Channel to account for registration and periodic re-registration messaging.
The chart in Figure 4-3 “Channel Loading with GPS Revert Channels” illustrates the Good to Fair
user experience area, similar to that in Figure 4-1 “Number of Users per Slot versus User
Experience”, for voice traffic loading on the selected channel and GPS traffic loading on one or
November, 2008
System Design Considerations 153 more GPS Revert Channels. Note that this only accounts for loading the first and second factors and assumes registration messaging is evenly spread throughout the day.
Selected Channel and GPS Revert Channel Loading with High GPS
High Voice
1 GPS Revert Channel
Low Voice
3 GPS Revert Channels
Example
0 10 20 30
# of Users per Slot
40 50 60
Figure 4-3 Channel Loading with GPS Revert Channels
It can be seen in Figure 4-3 “Channel Loading with GPS Revert Channels” that the High Voice
Selected Channel User Experience and the single GPS Revert Channel User Experience are fairly similar in terms of user experience versus number of users on a slot. In this example, for the desired User Experience (identified on the above chart as the red horizontal example line), the
Selected Channel supports about 16 radios at a high voice profile and the single GPS Revert
Channel supports about 18 radios at a high GPS profile. For the high voice profile, which is defined
Profile” on page 146, 18 users would equate to 18 transmissions per minute.
It can also be seen in Figure 4-3 “Channel Loading with GPS Revert Channels” that the Low Voice
Selected Channel User Experience and the three GPS Revert Channel User Experience are fairly similar in terms of user experience versus number of users on a slot. In this example, for the desired User Experience, the Selected Channel supports about 51 radios at a low voice profile and the three GPS Revert Channels support about 57 radios at a high GPS profile. For the low voice
distributed over three channels.
In the previous examples, it can be seen that the voice rate and the GPS rate cannot always be considered as independent when designing a system. Though three GPS Revert Channels are able to support 57 high GPS profile users, the Selected Channel is unable to support 57 high voice profile users. Therefore, when designing a system, both the Selected Channel loading and the
GPS Revert Channel(s) loading must be thoroughly considered.
The table below provides guidance for determining the maximum number of SUs supported on various numbers of GPS Revert Channels with one minute and two minutes update rates. It is important to note than maximum loading will essentially keep a repeater keyed up at all times.
Update rates of less than one minute are not recommended in order minimize the impact on the
November, 2008
154 System Design Considerations
Selected Channel features (voice, control and/or data). Care must also be taken to analyze if the
Selected Channel can accommodate the anticipated voice traffic for a large number of subscribers.
1 GPS Revert
Channel
2 GPS Revert
Channels
3 GPS Revert
Channels
SUs supported at
1 minute update rate
SUs supported at
2 minute update rate
20
40
40
80
60
120
Though GPS Revert Channels can significantly increase the number of SUs providing location updates, it is important to remember that when powered up, an SU needs to register with both
Presence and Location Applications before it can send location updates. If a large number of SUs happen to be powered up in a relatively short period of time, the Selected Channel may become overwhelmed with registration traffic and the system’s voice handling capacity will be impacted.
Therefore, if this situation must occur, the following should be kept in mind.
• Keep voice traffic on the Selected Channel to a minimum. This causes the registration messages to be queued in the radio and the control station.
• As a rule of thumb, expect about three successful registrations per minute. Therefore, a fleet of 60 radios could require 20 minutes to successfully register. In order to minimize registration traffic, the radios can be gradually powered on at a rate of three per minute during the estimated time frame.
November, 2008
System Design Considerations 155
4.5 Multiple Digital Repeaters in Standalone Mode
Multiple repeaters may be required to provide sufficient RF coverage. Large geographical regions and areas with large natural boundaries (i.e. mountains) are two examples. Also, regions with a large number of subscribers may need additional repeaters to relieve RF congestion.
The digital mode of operation of the MOTOTRBO repeater provides new capabilities to resolve common problems associated with deploying multiple repeaters in a system. The techniques described in the sections below can also be used to resolve problems associated with interfering
RF signals from adjacent radio systems.
4.5.1 Overlapping Coverage Area
As with analog radio systems, when digital radio systems are separated by frequency or distance
there are no negative interactions between the systems which need to be addressed. Figure 4-4
“Multiple Repeaters” shows two systems which operate on a common set of frequencies but are
physically separated so that there are no interactions between the systems.
F1 up F2 down
F1 up
F2 down
Site 2
Site 1
Figure 4-4 Multiple Repeaters
Similarly, Figure 4-5 “Multiple Repeaters with Overlap” shows two systems which overlap in space
but operate on a difference set of frequencies so that there are no negative interactions.
F1 up F2 down
F3 up F4 down
Site 1
Site 2
Figure 4-5 Multiple Repeaters with Overlap
November, 2008
156 System Design Considerations
Issues arise, however, when repeaters operate on common frequencies and have overlapping
regions. Figure 4-6 “Multiple Repeaters with Overlap and Common Frequencies” shows that when
a radio transmits in a region of overlap, repeaters from both systems retransmit the received signal. Analog radio systems often use PL/DPL to resolve these types of problems. With the
MOTOTRBO repeaters operating in digital mode, this issue can be resolved by assigning a unique color code to each repeater and programming the associated radios, using CPS, with the matching color code.
F2 down
F2 down
F1 up
Site 1
Site 2
Figure 4-6 Multiple Repeaters with Overlap and Common Frequencies
4.5.2 Color Codes in a Digital System
Color codes (or “CC” in the images) are defined by the Digital Mobile Radio (DMR) standard and can be used to separate two or more MOTOTRBO digital radio systems which operate on
common frequencies. Figure 4-7 “Multiple Digital Repeaters with Unique Color Codes” shows two
MOTOTRBO radio systems which operate on common frequencies but have uniquely defined color codes.
CC = 5
CC = 10
F2 down
Site 1
F1 up
(CC=5)
Site 2
CC = 5
CC = 10
Site 1
F1 up
(CC=10)
Site 2
F2 down
Figure 4-7 Multiple Digital Repeaters with Unique Color Codes
November, 2008
System Design Considerations 157
Color codes are assigned as channel attributes on the radios, allowing a single radio to communicate with multiple sites each having a uniquely defined color code.
4.5.3 Additional Considerations for Color Codes
The total number of available color codes per frequency is 16. From a radio user’s perspective the color code is similar in nature to a Group ID. However, it should not be used for this purpose. Just as Groups are intended to separate users into groups, the color code is intended to uniquely identify systems or channels which operate on common frequencies.
Multiple repeaters operating on common frequencies with large areas of overlap, as shown in
Figure 4-8 “Color Code with Site Congestion”, could be configured with unique color codes. This
would allow both repeaters to operate with some degree of independence. However, the radio users should expect to see an increase in “Channel Busy” indications since transmissions from both repeaters will be detected by users of both systems. In other words, the RF congestion for this region would be the sum of transmissions from both repeaters. It should be noted that under all circumstances the users with the correct corresponding color codes receive only the transmission intended for them.
When two sites with the same frequency but different color codes overlap, it is important to set the subscriber’s Admit Criteria appropriately. It is recommended that the subscribers are provisioned with Admit Criteria set to Channel Free to ensure subscriber’s from a Site is polite when another on the overlapping Site is transmitting, and also polite to any other analog transmission on the frequency. If configured to Color Code Free, the subscribers are only polite to their own color code, and will wake up their repeater even if the other repeater is currently transmitting. When there is a large overlap between adjacent sites, this usually causes major interference and results in both repeater signals being unusable in the overlapping areas. When configured to Always, the subscribers are never polite, even to their own color code. Again, this results in both repeaters being awake and transmitting at the same time which causes interference in areas of overlap.
If this configuration is necessary, it is recommended to minimize the areas of overlap as much as possible and to use an Admit Criteria of Color Code Free. Remember that these two repeaters will be sharing bandwidth and should be loaded appropriately.
Site 1
F1
CC = 5 up
(CC=5)
CC = 10
X (Channel Busy)
F1 up
F2 down
(CC=10)
Site 2
Figure 4-8 Color Code with Site Congestion
November, 2008
158 System Design Considerations
4.6 Multiple Digital Repeaters in IP Site Connect Mode
The main problem with the standalone configuration of multiple digital repeaters is that a radio at a site can participate only in the calls that originate at that site. The IP Site Connect configuration removes this restriction and allows a radio to participate in a call originating at any site. In IP Site
Connect configuration, repeaters communicate among themselves using a back-end wire line network. A call originating at a repeater is transmitted by all the repeaters in the IP Site Connect system. Since all repeaters participate in a call, it is necessary that all the repeaters have the same call related parameters (e.g. Call Hang Times, System Inactivity Time, Time Out Time).
4.6.1 System Capacity
In IP Site Connect configuration, MOTOTRBO supports a maximum of 15 IP Site Connect devices, where IP Site Connect devices include a maximum of five host PCs of RDAC-IP applications, disabled repeaters, enabled repeaters in analog mode, and enabled repeaters in digital mode (both slots in wide area mode, one slot in wide area mode and one in local mode, and both slots in local mode).
A channel in IP Site Connect configuration supports the same number of radios supported by a single site configuration. Note that an IP Site Connect configuration increases the coverage area and not the call capacity of a single site configuration.
4.6.2 Frequencies and Color Code Considerations
The figure below shows an example of two IP Site Connect systems with overlapping coverage areas. The frequencies and color code of repeaters should follow the following rules:
• The geographically adjacent repeaters of an IP Site Connect system should use different frequencies. Their color code can be either same or different.
• If the frequencies of the geographically adjacent repeaters of two IP Site Connect systems are the same, then their color codes should be different. It is not advisable to keep the same frequencies because in areas of overlap, there will be destructive interference. Note that an
IP Site Connect configuration does not support simulcast.
• A system may be sharing the channels with other systems over multiple sites. It is possible that two systems (named here as Sys1 and Sys2) may be using the same (frequencies, color code) pair at two different sites (say, Site1 and Site2). During automatic site search
(Passive Site Search), a Sys1’s radio at Site2 will find Sys2’s repeater and will stay on that
November, 2008
System Design Considerations 159 channel. This is not a desirable situation. A way to avoid this situation is to ensure that all the (frequencies, color code) pairs of all the overlapping systems are unique.
F1 up F2 down F3 up F4 down F1 up F2 down
IP Site Connect
System 2
F1 up
CC = 5
Site 1
F2 down
F7 up CC = 4
Site 2
F8 down
F3 up
CC = 5
Site 3
F4 down
Figure 4-9 Example of Two IP Site Connect Systems with Overlapping Coverage Areas
4.6.3 Considerations for the Back-End Network
The back-end network can be a dedicated network or an internet provided by an Internet Service
Provider (ISP). ISPs provide a range of technologies such as dial-up, DSL (typically ADSL), Cable modem, Broadband wireless access, Canopy, ISDN, Frame Relay, Satellite Internet access, etc.
In some cases dedicated links or networks can be effectively used or deployed, removing the monthly fees associated with public networks. The back-end network cannot be based on dial-up connection (due to small bandwidth) or Satellite Internet access (due to large delay).
A repeater has three network interfaces: Ethernet, USB, and Over-The-Air. A repeater uses its
Ethernet port to communicate among them using IPv4/UDP. Since UDP does not support confirmation, an IP Site Connect system provides its own acknowledgement and retries mechanism for critical activities. Note that the Ethernet port is not a default IP gateway of a repeater, i.e. an IP datagram arrived from USB or Over-The-Air is not automatically routed to the
Ethernet port.
It is not necessary to get a static IPv4 addresses for IP Site Connect devices (except for the
Master). The IPv4 address of an IP Site Connect device can be dynamic. In this case, the IPv4 address is allocated by a DHCP server. The dynamic nature of the IPv4 address implies that the address may change every time it powers-on or even periodically (every few hours) while the IP
Site Connect device is on. The dynamic address of a repeater is selected by selecting the DHCP option in the repeater CPS. It is recommended that the lease time of the IPv4 address from the
DHCP should be kept as long as possible. Note that a change in the IPv4 address of an IP Site
Connect device causes short disruption of service for the device. For static IPv4 address, the
DHCP option should not be selected and the CPS user should provide the static IPv4 address, and the gateway’s IPv4 address and netmask.
An IP Site Connect configuration uses a procedure called “Link Management” to keep an IP Site
Connect device aware of the presence, the current IPv4 addresses, and UDP ports of other IP Site
Connect devices. The Link Management requires only one of the repeaters (called an Master) to act as a broker of IPv4/UDP addresses. The Master gets a static IPv4 address from its ISP and the
Master’s IPv4/UDP address is configured into all the IP Site Connect devices.
November, 2008
160 System Design Considerations
The Master’s IPv4/UDP address refers to its address as seen from the back-end network. Note that a firewall/NAT may translate the address in customer network into another address in the back-end network.
An IP Site Connect device registers its IPv4/UDP address during power-on and upon a change in its IPv4/UDP address with the Master. The Master notifies to all the IP Site Connect devices whenever the IPv4 address of an IP Site Connect device changes. An IP Site Connect device maintains a table of the latest IPv4 addresses of other IP Site Connect devices and it uses the table to send an IPv4/UDP message to another IP Site Connect device.
The IP Site Connect devices may be behind firewalls. For successful communication between two
IP Site Connect devices (say R1 and R2), the firewall of R1 must be open for messages from R2 and vice versa. Since the IPv4/UDP address of an IP Site Connect device is dynamic, it is not possible to manually configure the firewalls. The Link Management procedure overcomes this problem by periodically, for example, setting the Keep FW Open Time to every 6 seconds, sending a dummy message from R1 to R2 and vice versa. On a receipt of an outbound message (say, from
R1 to R2), the R1’s firewall keeps itself open for a short duration of approximately 20 seconds for an inbound message from R2. An IP Site Connect device (say, R1) sends the dummy message to another IP Site Connect device (say, R2) only if R1 has not sent any message to R2 in last Keep
FW Open Time. The value of Keep FW Open Time is customer-programmable and should be kept less than the duration for which the firewall remains open for inbound messages. Exchange of dummy messages between two IP Site Connect devices also acts as a “Keep Alive” messages.
They are required, even if there is no firewall or the firewall is configured to keep itself open for any message destined to the IP Site Connect device.
4.6.3.1 Automatic Reconfiguration
An IP Site Connect system automatically discovers the presence of a new IP Site Connect device.
The new IP Site Connect device is configured with the IPv4/UDP address of the Master. On power-on, the new IP Site Connect device informs its IPv4/UDP address to the Master and the
Master informs all the other IP Site Connect devices about the presence of a new IP Site Connect device. This allows adding an IP Site Connect device to a live IP Site Connect system. This simplifies the installation/addition of an IP Site Connect device as there is no need to take the system down and configure other IP Site Connect devices with the IPv4/UDP address of the new
IP Site Connect device.
The periodic link management messages between an IP Site Connect device and the Master also act as “keep alive” messages. In absence of messages from an IP Site Connect device for one minute, the Master concludes that either the IP Site Connect device has failed or the network inbetween and the Master informs all the other IP Site Connect devices about the absence of the IP
Site Connect device. An IP Site Connect device also maintains periodic link management messages with every other IP Site Connect device. In absence of messages from another IP Site
Connect device for one minute, the IP Site Connect device concludes that either the other IP Site
Connect device has failed or the failure is within the network in between. Thus, the link management messages allow an IP Site Connect system to reconfigure itself on failure of one or more IP Site Connect devices and the system continues to provide services with the available IP
Site Connect devices. In case of network failure, it is possible that an IP Site Connect system becomes multiple IP Site Connect systems, where each system has a subset of original set of IP
Site Connect devices. All the new systems continue to provide the services that are possible with their subset of IP Site Connect devices. Note that there will be only one system that has the
Master. When the back-end network recovers, the multiple systems automatically become one system. When an IP Site Connect system has only one repeater, then both the slots of the repeater repeat only locally (i.e. over-the-air) as per the MOTOTRBO Single Site specifications.
November, 2008
System Design Considerations 161
A repeater operates in multiple modes such as disabled, locked, knocked down, enabled and analog, enabled and digital with voice/data or control services, and single or multiple site operation for each slot. The repeater informs the Master whenever its mode of operation changes and the
Master informs to all the other IP Site Connect devices. This allows the IP Site Connect system to adapt its operation when the mode changes. Note that only an enabled and digital repeaters (with a channel enabled for multiple site operation) participate in voice/data/control communication across multiple sites.
A disadvantage of link Management is that the Master becomes a single point of failure. But the consequence of failure of the Master is limited. The IP Site Connect system continues to function except that it is not possible to add an IP Site Connect device into the system. If an IP Site
Connect device powers on, while the Master is in failed state, then it will not be able to join the IP
Site Connect system. On failure of the Master, it is possible to switch a redundant IP Site Connect device to act as an Master. The static IPv4 address and the UDP port number of the redundant IP
Site Connect device should be same as that of the failed Master; otherwise all the IP Site Connect devices will require to be reconfigured with the IPv4 address and the UDP port number of the new
Master.
4.6.3.2 Characteristics of Back-End Network
To create a proper back-end network design, it is important to know its characteristics. This section explains four issues dealt within the back-end network.
4.6.3.2.1 Delay/Latency
Back-end network delay or latency is characterized as the amount of time it takes for voice to leave the source repeater and reach the destination repeater. Three types of delay are inherent in the back-end networks:
• propagation delay
• serialization delay
• handling delay
Propagation delay is 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 is the amount of time it takes the source repeater to actually place a packet byte by byte onto the back-end network interface. Generally, the effect of serialization delay on total delay is relatively minimal but since IP Site Connect system sends a voice packet one-by-one to all the repeaters, the serialization delay for the last destination repeater is (# of repeaters - 1) times the serialization delay for the first destination repeater.
Handling delay defines many different types of delay caused by the devices (e.g. secure routers) that forward the packet through the back-end 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 at a given interval.
The CPS allows setting the Total Delay (i.e. sum of propagation delay, serialization delay, and handling delay) to be High (90 ms) or Normal (60 ms) in both the repeaters and the radios. Note that radios also support higher value (500 ms) of total delay, which should not be used in case of
IP Site Connect system. The default is Normal. This is used to derive values for other parameters
November, 2008
162 System Design Considerations such as Arbitration Interval and Call Hang Times in repeaters and Ack Wait times in radios. For proper functioning of an IP Site Connect system, all the repeaters and radios should have the same delay setting.
It is recommended that propagation and handling delays between repeaters should be measured
(e.g. by “pinging”) between all pairs of repeaters.
The total delay is equal to the maximum of the measured values + (# of repeaters - 1) * (1/2 +
1000/BW in Kbps) ms, where the BW is the available bandwidth of the back-end network.
If the total delay is less than 60 ms then the setting should be Normal. If the total delay is more than 60 ms but less than 90 ms then the setting should be High. The IP Site Connect system will not work satisfactorily, with occasional failure of arbitration, hang time and data link layer acknowledgements, for a back-end network having total delay of more than 90ms. The disadvantage of the setting at 90ms is that there is an increase to audio throughput delay.
4.6.3.2.2 Jitter
Jitter is the variation of packet inter-arrival time. The source repeater is expected to transmit voice packets at a regular interval (i.e. every 60 ms for one channel). These voice packets can be delayed throughout the back-end network and may not arrive at that same regular interval at the destination repeater. The difference between when the packet is expected and when it is actually received is called Jitter. To overcome the effect of jitter, the IP Site Connect system employ a Jitter
Buffer of fixed 60 milliseconds. If a packet does not arrive at a destination repeater within the 60 ms after the expected time then the repeater assumes the packet is lost, replays a special erasure packet, and discards the late arriving packet. Because a packet loss affects only 60 ms of speech, the average listener does not notice the difference in voice quality. Thus, a jitter of more than 60 ms degrades the audio quality.
4.6.3.2.3 Packet Loss
Packet loss in IP-based networks is both common and expected. To transport voice bursts in timely manner, IP Site Connect system cannot use reliable transport mechanisms (i.e. confirmed packets) and therefore while designing and selecting the back-end network it is necessary to keep packet loss to a minimum. The IP Site Connect system responds to periodic packet loss by replaying either a special packet (in the case of voice) or the last received packet (in the case of data). In the case of voice, the ongoing call ends if six consecutive packets do not arrive within 60 ms of their expected arrival time. In the case of data, the repeater waits for the expected number of packets (as per the data header) before ending the call.
4.6.3.2.4 Network Bandwidth Considerations
Bandwidth is the amount of data transferred to and from a network device, often referred to as the bit rate. Bandwidth is measured in bits per second or kilo-bits per second (kbps). When designing an IP Site Connect system, it is important to understand the needs of each IP Site Connect device so that the appropriately rated network connection for each site can be chosen.
If a customer has high speed network connections between sites, these calculations may not be as important, but if they are working on lower speed public Internet Service Providers (ISPs) it is good practice to understand these values and plan accordingly. If the minimum amount of bandwidth is not available, the end user may experience audio holes or even dropped calls. Radio
November, 2008
System Design Considerations 163 to Radio Data messaging or RDAC commands may not be successful on the first attempt, or may be dropped all together. In general, the quality of service may suffer if substantial bandwidth is not available.
Note that for most Internet Service Providers, the uplink bandwidth is the limiting factor. The downlink bandwidth is usually multiple factors above the uplink bandwidth. Therefore, if the uplink requirements are met, the downlink requirements are almost always acceptable. Some ISPs may state they provide a particular bandwidth, but it is important to verify the promised bandwidth is available once the system is installed and throughout operation. A sudden decrease in available bandwidth may cause the previously described symptoms.
It is also important to note that if the wide area network connection is utilized by other services (file transfer, multimedia, web browsing, etc.), then the IP Site Connect devices may not have the appropriate bandwidth when required and quality of service may suffer. It is suggested to remove or limit these types of activities. In addition, overusage of the RDAC application itself may cause increased strain on the network during times of high voice activity. It is recommended that RDAC commands be kept to a minimum unless appropriate bandwidth has been allocated.
4.6.3.2.4.1Required Bandwidth Calculations
The amount of bandwidth an IP Site Connect device requires is dependent on a of variety factors.
The most important factor to understand is that the bandwidth required for one particular device is dependent on how many other devices or peers it has in the IP Site Connect system. Equally important is the type of devices. Recall that an IP Site Connect system can contain repeaters that have two channels operating in wide area, one channel operating in wide area, or no channels operating in wide area, such as local channels only. Channels, or slots, operating in local area mode do not send their voice traffic over the network. Recall that one repeater within the IP Site
Connect system acts as the Master. This repeater requires some additional bandwidth. The IP Site
Connect system may also contain analog repeaters, disabled repeaters, and RDAC applications.
These devices do not send voice over the network, but they do require the bandwidth to support the standard link management and control signaling.
For a quick reference, the graphs below show the required bandwidth for two simple IP Site
Connect system configurations. The first shows the required bandwidth for various size systems where every repeater in the system utilizes both channels, or slots, as wide area. The second shows the required bandwidth for various size systems where every repeater in the system utilizes one channel, or slot, as wide area, and the other channel, or slot, as local area. In each system,
November, 2008
164 System Design Considerations one RDAC is present, repeater authentication is enabled, and Secure VPN is not being utilized in the routers.
600
Bandwidth required vs Number of Repeaters
( 2 Wide Area Channels, with RDAC )
500
Master
Non-Master
400
300
200
100
0
2 4 6 8 10
Number of Repeaters
12 14
600
Bandwidth required vs Number of Repeaters
( 1 Wide Area Channel, with RDAC )
500
Master
Non-Master
400
300
200
100
0
2 4 6 8 10
Number of Repeaters
12 14
Figure 4-10 Required Bandwidth for Two Simple IP Site Connect System Configurations
Note that although the two examples above may represent typical IP Site Connect configurations, and may provide a quick snapshot of the bandwidth requirements for a particular size system, more complicated configurations will require additional calculations.
The following equation should be used to calculate the bandwidth for each IP Site Connect device in the IP Site Connect system, and then added together at sites where multiple devices reside behind one wide area connection.
BW
VC
= 15 kbps = Bandwidth required to support Wide Area Voice or Data (1 slot)
BW
LM
= 6 kbps = Bandwidth required to support Link Management
BW
IR
= 3 kbps = Bandwidth required to support Master Messaging
BW
RD
= 55 kbps = Bandwidth required to support RDAC commands
Number of Wide Area Channel Peers* for Slot 1
Number of Wide Area Channel Peers* for Slot 2
Total Number of IP Site Connect Peers*
If Master, Total Number of IP Site Connect Peers*
RDAC Traffic x BW
VC x BW
VC x BW
LM x BW
IR kbps = kbps = kbps = kbps =
BW
RD kbps kbps kbps kbps kbps
+
Required Uplink/Downlink Bandwidth kbps
* Peer does not include self.
November, 2008
System Design Considerations 165
To help demonstrate the use of the above equation on a more complicated IP Site Connect system, take the following example system shown in the diagram below. This system has six total
IP Site Connect devices at three sites; five repeaters and one RDAC. Three of the repeaters have both channels configured as wide area, one has a wide area channel and a local channel, and the last repeater has two local channels. The routers are not utilizing Secure VPN.
Repeater 2
WAC 1
WAC 2
160 kbps
Router
160 kbps
Repeater 3
WAC 1
WAC 2
160 kbps Network
Local Area
Network
Router
245 kbps
Wide Area
Network
260 kbps
Router
Repeater 4
LC 1
LC 2
85 kbps
130 kbps
Router
130 kbps
WAC 1
LC 3
Repeater 5
Local Area
Network
175 kbps
Master
Repeater 1
WAC 1
WAC 2
85 kbps
Router = Firewall, NAT, or Router
WAC = Wide Area Channel
LC = Local Channel
RDAC = Remote, Diagnostics , and Control.
Computer
RDAC
Figure 4-11 Example System for Calculating Bandwidth Requirements without Secure VPN
Let us start with Repeater 1. Repeater 1 is an Master and has two wide area channels. The first wide area channel has three peers and the second wide area channel has two peers. Note that since Repeater 4 and Repeater 5 have local area channels, these are not considered wide area channel peers. It is also important to remember that a peer does not include the device currently being calculated.
Each calculation provides enough bandwidth to support an RDAC command during times of high activity. This assumes that only one RDAC command occurs at a time and is not utilized often. If it is expected that multiple RDAC applications will be performing commands on repeaters often and simultaneously, one might wish to increase the bandwidth to support these types of activities.
The detailed bandwidth calculation for Repeater 1 is as follows:
Number of Wide Area Channel Peers* for Slot 1
Number of Wide Area Channel Peers* for Slot 2
3 x
2 x
15
15 kbps = kbps =
45
30 kbps kbps
November, 2008
166 System Design Considerations
Total Number of IP Site Connect Peers*
If Master, Total Number of IP Site Connect Peers*
RDAC Traffic
5 x
5 x
6
3 kbps = kbps =
+
30
15
55
– kbps kbps kbps
–
Required Uplink/Downlink Bandwidth 175 kbps
* Peer does not include self.
Using the same method for all IP Site Connect devices in the example system yields the following:
Number of Wide Area Channel Peers* for Slot 1
Number of Wide Area Channel Peers* for Slot 2
Total Number of IP Site Connect Peers*
If Master, Total Number of IP Site Connect Peers*
3
2
5
5
3
2
5
0
3
2
5
0
0
0
5
0
3
0
5
0
Required Uplink/Downlink Bandwidth (kbps) 175 160 160 85 130 85
* Peer does not include self.
IP Site Connect devices behind a single router need to be added together to acquire the wide area network bandwidth requirements. See the final bandwidth requirements in the figure above.
Note that an analog repeater or disabled repeater connected to the IP Site Connect system would require the same amount of traffic as a local only repeater (Repeater 4). But keep in mind that if the disabled repeater will eventually be enabled without disabling a different repeater, the bandwidth of the enabled repeater should be accounted for in the bandwidth plan.
5
0
0
0
November, 2008
System Design Considerations 167
4.6.3.2.4.2Required Bandwidth Calculations While Utilizing a Secure Virtual
Private Network
As was discussed in previous chapters, peer-to-peer communications over the network are
Connect supports the ability to work through a Secure Virtual Private Network (VPN). Secure VPN is not a function of the IP Site Connect device but rather of the router. It is important to note that
Secure VPN does add the need for additional bandwidth and may introduce additional delay.
For a quick reference, the graphs below show the required bandwidth for the two previously discussed simple IP Site Connect system configurations, but in this case utilizing routers with
Secure VPN enabled and repeater Authentication Disabled. When utilizing Secure VPN routers, repeater authentication is not necessary since the Secure VPN utilizes its own authentication. As can be seen, the bandwidth requirements per device increase substantially. This should be taken into account when planning for bandwidth.
800
Bandwidth Required vs Number of Repeaters
( 2 Wide Area Channels, with RDAC, Secure VPN )
700
Master
Non-Master
600
500
400
300
200
100
0
2 4 6 8 10
Number of Repeaters
12 14
300
200
100
0
2
800
Bandwidth Required vs Number of Repeaters
( 1 Wide Area Channel, with RDAC, Secure VPN )
700
Master
Non-Master
600
500
400
4 6 8 10
Number of Repeaters
12 14
The following parameters should be used in the previous equation to calculate the bandwidth requirements of each device in the system when secure VPN in the routers is enabled and repeater authentication is disabled.
BWVC = 23 kbps = Bandwidth required to support Wide Area Voice or Data with Secure VPN
BWLM = 5 kbps = Bandwidth required to support Link Management without authentication
BWIR = 4 kbps = Bandwidth required to support Master Messaging
BWRD = 64 kbps = Bandwidth required to support RDAC commands
NOTE: The preceding data was compiled using the Linksys EtherFast Cable/DSL VPN Router with four-port switch. Model: BEFVP41. Other routers using different algorithms may yield different results.
November, 2008
168 System Design Considerations
4.6.4 Flow of Voice/Data/Control Messages
The flow of voice/data/control messages from a radio to its repeater for an IP Site Connect configuration is the same as that of single-site configuration of MOTOTRBO system. The major changes in the flow of messages (between single site operations and multiple site operations) are in the processing of a message in the repeaters and the additional delays introduced due to reasons such as serialization, propagation, arbitration, and the nonalignment of slots between repeaters. This section describes the changes.
On receipt of a start up of a voice/data/control call from a radio over a slot, a repeater sends it over the back-end network to all the repeaters that are enabled, operating in digital mode, and the corresponding slot is configured for multiple site operation. This implies that at any time at most two calls are active in an IP Site Connect system if both slots are configured for multiple site operation.
In an IP Site Connect configuration, calls can start concurrently at more than one repeater and due to different messaging delay between repeaters, it is possible that different repeaters select different calls for repeating over the air. To overcome this problem, on receipt of a start up of a voice/data/control call either over the air (from a radio) or over the back-end network (from other repeaters), a repeater starts an arbitration window for a duration of twice the Inter-Repeater
Messaging Delay. At the end of the arbitration window, the repeater selects one of the calls received during this window using a procedure that ensures that all the repeaters select the same call. After selection, a repeater starts repeating the bursts of the selected call. A disadvantage of the arbitration procedure is that it increases the System Access Time.
The voice/data/control messages are sent burst by burst between repeaters. Like a single-site system, a repeater does no data link layer processing (e.g. acknowledgement, decryption). If required, the voice and data messages are encrypted / decrypted by the source and destination radios. A repeater sends the voice or data packet to other repeaters as it receives over the air.
Also in case of data message, the destination radio sends the Ack/Nack and if required the
Selective ARQ takes place between the source and destination radios and not between a radio and its repeater.
A call is a session of one or more transmissions from participating radios. To ensure continuity between transmissions, the single site configuration of MOTOTRBO has Hang Time, during which the channel is reserved for participant(s) of the ongoing call. The IP Site Connect configuration extends the concept of session to include Remote Monitor call, Individual and group data call, and
CSBK Call (e.g. Call Alert, Radio Check, Inhibit/Uninhibit). The Hang Time ensures that a call continues with minimum interruptions.
The flow of data messages from a radio to an application (e.g. Location or Text Messages) in an IP
Site Connect system is similar to a single-site configuration of MOTOTRBO. A data packet flows burst-by-burst to a Control Station connected to the Application Server. The Control Station assembles the bursts into a PDU. If the PDU is confirmed then the Control Station handles the data link layer acknowledgement. If the PDU is encrypted then the Control Station decrypts the
PDU. The Control Station strips the data link layer headers and forwards the resulting datagram to the Application Server.
All the data applications of the single site configuration of MOTOTRBO are compatible with IP Site
Connect configuration. An IP Site Connect configuration supports the revert channels, where a revert channel can be a channel of another IP Site Connect system. The GPS data on a GPS revert channel are sent unconfirmed in IP Site Connect mode. This increases the throughput of the
November, 2008
System Design Considerations 169
GPS data as the data link layer acknowledgement over the back-end network is slower due to delays associated with the back-end network.
4.6.5 Security Considerations
The single site configuration of MOTOTRBO offers two types of privacy mechanisms over the air -
Basic Privacy and Enhanced Privacy. See “Voice and Data Privacy” on page 62. The IP Site
Connect configuration not only supports both the mechanisms, but also extends them over the back-end network. A repeater does not decrypt the encrypted packets. It simply passes the packets as received over the air to other repeaters. Since the two mechanisms are not compatible, all the radios and repeaters of an IP Site Connect system should support the same privacy mechanism. This should be ensured during configuration. Note that the privacy mechanisms protects only the voice or data payloads. They do not protect the voice or data headers, or control messages (i.e. CSBK) or system messages (between repeaters).
An IP Site Connect system optionally offers authentication of all the packets sent between IP Site
Connect devices. Each packet has a 10 bytes long cryptographic signature. The signature is created using Keyed-Hash Message Authentication Code (HMAC), which is a National Institute of
Standards and Technology (NIST) standard. The hashing is done using SHA-1 algorithm. The
HMAC uses a 20 bytes long symmetric keys and generates a 20 bytes long signature. To reduce the bandwidth requirement over the back-end network, the 20 bytes long signature is truncated to
10 bytes before attaching to the packet. Packet authentication prevents an attacker from using an impersonator as an IP Site Connect device in order to get access to the IP Site Connect system.
This feature, if selected by a customer, requires the customer to manually configure the same key to all the IP Site Connect devices. Note that the IP Site Connect system does not support rekeying remotely.
The above authentication mechanism does not provide protection against the replay attacks. For a more secure authentication, an IP Site Connect configuration should use Secure VPN routers to connect with the back-end network. Secure VPN routers can optionally provide confidentiality of all the messages including system messages (between IP Site Connect devices), control messages
(i.e. CSBK), and voice or data headers. A disadvantage of using Secure VPN Routers is that the
IP Site Connect requires more inbound and outbound bandwidth from the ISP. The use of Secure
VPN routers make the authentication mechanism of IP Site Connect redundant and it is recommended that it should be disabled. This saves some bandwidth over the back-end network.
4.6.6 General Considerations When Setting Up the Network
Connection for an IP Site Connect System
Network setup and configuration varies significantly depending on the complexity of the equipment and IP network the system resides on. It is always wise to communicate with the Network
Administrator during installation and during the design phase as they are likely be the individuals configuring the network equipment and own a great deal of knowledge in this area. Below is a short list of items to keep in mind when setting up or when troubleshooting the networks of IP Site
Connect systems.
• When assigning Static IP addresses within a Network, it must not conflict with another static
IP address. As with any IP conflict, this can cause a disruption to the IP Site Connect traffic.
Also, ensure that the static IP address does not fall into the DHCP assignable range. This can cause an IP conflict if the address is dynamically assigned to another device on the network.
November, 2008
170 System Design Considerations
• If other network devices are present on the same IP network as the IP Site Connect devices, it is good practice to setup Quality of Service (QoS) rules in the Internet Router. This ensures that the IP Site Connect packets have priority over other traffic on the system. Not doing this could cause audio performance degradation or lost transmissions when other devices on the system are excessively utilizing the network. There are various methods routers use to provide QoS. It is commonly performed by configuring a range of UDP ports or IP Addresses a specific amount of upstream and downstream bandwidth. The default
UDP port for IP Site Connect is 50000. For details on calculating the required bandwidth, see section
“Required Bandwidth Calculations” on page 163.
• Verify that the customer network equipment is not blocking the IP Addresses or UDP Ports
(default 50000) utilized by the IP Site Connect system. This is commonly done by a firewall or other security device. Consult the customer’s Network Administrator or Internet Service
Provider.
• Inquire with the Internet Service Provider if there are any caps on bandwidth usage per month. Some ISPs do not allow the customer to exceed a particular upload or download limit per month. Since IP Site Connect systems stream voice over the internet, it may be possible to surpass this limit on extremely high usage systems. As a reference point, a five site system under nominal load could use around 20GB per month, where as a 15 site system under nominal load could use around 65GB per month. For most ISPs, this will not be an issue.
• When configuring routers with VPN links, it is wise to increase the IPSec Key Life Time
(KLT) Timers to around 13 to 24 hours. It is recommended to set Phase 1 KLT to 24 hours, and Phase 2 KLT to 13 hours. Some low-end routers cause a disruption to ongoing voice and data when renegotiating keys after the Key Life Time Timer expires. This is especially noticeable when multiple VPNs are configured with identical Key Life Time Timers since the router will need to re-calculate numerous keys at the same time. It is best practice to offset each VPN’s Key Life Time Timers by 10 minutes.
November, 2008
System Design Considerations 171
4.6.7 Considerations for Shared Use of a Channel
To take care of shared use of a physical channel, a repeater (e.g. green repeater) of an IP Site
Connect system always monitor its Rx frequency and does not transmit if the Received Signal
Strength Indicator (RSSI) from radio(s) of some other radio system is greater than a configurable threshold. This ensures that an IP Site Connect system will not use a channel if another repeater, in vicinity, is currently using the channel. The RSSI threshold is CPS programmable in the range of
–40 dB to –130 dB. The threshold should be chosen wisely otherwise interference from background noise may inhibit a repeater from transmitting. The RDAC application can be used to measure the inbound RSSI of an interfering signal if required.
The figure below shows the transmission of red radio interfering with the green repeater.
F1
Interfering
Signal
F1
F1
F2
Figure 4-12 An Example of Interference at Receive Frequency
The above monitoring scheme of Rx frequency is not sufficient in the following conditions:
• In VHF range, in some countries (including USA), the transmit frequency is not tightly bound to a receive frequency
• There is no radio in the other radio system that is currently using the system.
• The other radio system is being used by a console.
• The radio that is using the other radio system is too far from the IP Site Connect system.
To take care of above conditions, it is recommended that a repeater of an IP Site Connect system should use an external RF receiver. The external RF receiver is tuned to the transmit frequency of the repeater and activates a GPIO compatible output when it receives RF signal. The output of the receiver is connected to the “Transmit Inhibit” (an input GPIO line) of the repeater. The repeater does not wake up if its “Transmit Inhibit” line is active. An attenuator can be inserted between the antenna and the receiver, if it is required to change the threshold of the received signal. The net effect of this configuration is that the repeater does not wake up if there is another repeater transmitting at its Tx frequency. The repeater CPS allows its user to associate an input line of the
November, 2008
172 System Design Considerations
GPIO lines with “Transmit Inhibit”. This arrangement is also applicable to single-site repeaters.
The figure below shows the transmission of red repeater interfering with the green repeater.
Interfering
Signal
F2
F1
F2
Figure 4-13 An Example of Interference at Transmit Frequency
4.6.8 Migration from Single Site Systems
The hardware of radios (both portables and mobiles) and repeaters of MOTOTRBO’s single site system are fully compatible with the IP Site Connect configuration. To migrate to IP Site Connect system the customer is required to update the software of repeaters and reconfigure them. Some of the features of the single site radios may work in the IP Site Connect system but it is highly recommended that the software of the radios should also be updated. Data applications of single site configuration are fully compatible with the IP Site Connect configuration.
4.7 Data Sub-System Design Considerations
4.7.1 Computer and IP Network Configurations
The data applications in a MOTOTRBO system utilize IP/UDP communications, therefore it is necessary to design the IP configuration of the data capable devices. Although complex, it is important to understand how data traffic is routed from one radio to another in a MOTOTRBO system. This section details the different connects, and where they are used within a MOTOTRBO system.
4.7.1.1 Radio to Mobile Client Network Connectivity
As described in earlier chapters, the MOTOTRBO radio connects to a computer via USB. Once connected, the PC detects the connection, loads a driver, and establishes a new network interface. This network interface looks similar to a LAN or WLAN network interface to the PC. The radio acts like a DHCP server providing the PC with an IP, and setting its own IP as the default gateway.
November, 2008
System Design Considerations 173
The Radio IP address used for this connection is programmed into the MOTOTRBO radio in the network settings of the CPS. The Accessory IP value is not editable in the CPS. It will be updated based on the Radio IP. The first 3 octets are the same as the radio IP, the last octet will be the
Radio IP value + 1 (for example, if the Radio IP is 192.168.10.1, the Accessory IP will be automatically updated to 192.168.10.2).
• Accessory IP – provided via DHCP to the Network Interface on the PC
• Radio IP – used by the Radio to communicate with the PC
– provided to the PC as the default gateway
These IP addresses are only used for communication between the MOTOTRBO radio and the connected PC. It is recommended that the default values (Radio IP : 192.168.10.1, Accessory IP :
192.168.10.2) be used in all mobile client configurations. In other configurations where multiple
MOTOTRBO radios are connected to one PC, these values need to be different to prevent IP conflicts.
If the default IP address programmed in the radio, or the one provided to the PC conflicts with other network interfaces on the PC, then the Radio IP should be changed using the CPS. The radio also allows for the default UDP ports for the ARS, Text Message and Telemetry applications to be changed if there exists conflict within the PC. These UDP ports will need to be updated in the application configuration as well. Again, it is recommended that the default values be used whenever possible.
For best results, it is recommended that mobile clients do not have additional network interfaces.
Additional static routes may need to be manually entered in the mobile client PC if multiple interfaces are present. It is also recommended that any applications that attempt to broadcast network traffic be disabled in the PC. Unnecessary traffic sent to the MOTOTRBO radio may cause undesired congestion over the air.
The simple diagram below displays the IP connectivity between the Mobile Client and the
MOTOTRBO radio. Note that because these IP addresses are private and only used between the radio and the Mobile Client, it is recommended that they be duplicated on all Radio/Mobile Client configurations in the system.
MOTOTRBO Radio
192.168 .10.1
USB
192.168 .10.2
Mobile Client on a PC
Radio IP = 192 .168.10.1
Accessory IP = 192 .168.10.2
Radio IP Netmask = 255.255 .255.0
Figure 4-14 Connectivity between the Mobile Client and the MOTOTRBO Radio
November, 2008
174 System Design Considerations
4.7.1.2 Radio to Air Interface Network Connectivity
The MOTOTRBO radio must have an IP address to communicate with the MOTOTRBO network and other radios. The radio and the system uses the Individual Radio ID and CAI Network Address to construct its Radio Network IP to ensure uniqueness. The Individual Radio ID is found in the
General Settings section of the radio CPS, and the CAI Network Address is found in the Network
Settings section.
A Radio ID in MOTOTRBO is a 24 bit number that can range from 1 to 16776415, and is written in decimal format in the CPS.
16776415 is represented by a hexadecimal 24 bit number as FFFCDF. When broken into three 8 bits sections, this becomes FF, FC, and DF. This in decimal is 255, 252, and 223. Therefore, a radio that is configured with an Individual ID of 16776415 and a CAI Network address of 12 (the default), will have a Radio Network IP address of 12.255.252.223. Below are a few more examples
(all assuming the default CAI Network address of 12):
Unit ID = 00012045
Convert to Hexadecimal = 002F0D
Separate into 8 bit sections = 00, 2F, 0D
Each 8 bit section represents 1 octet of the IP address
Convert each section into decimal = 00, 47, 13
Assemble IP address from conversion above = 12.A.B.C where
A = The first 8 bit section in decimal format. In this example, A = 0
B = The second 8 bit section in decimal format. In this example B = 47
C = The third 8 bit section in decimal format. In this example C = 13
The IP address for Unit ID 12045 is: 12.0.47.13
Unit ID = 00000100
Convert to Hexadecimal = 000064
Separate into 8 bit sections = 00, 00, 64
Each 8 bit section represents 1 octet of the IP address
Convert each section into decimal = 00, 00, 100
Assemble IP address from conversion above = 12.A.B.C where
A = The first 8 bit section in decimal format. In this example, A = 0
B = The second 8 bit section in decimal format. In this example B = 0
C = The third 8 bit section in decimal format. In this example C = 100
The IP address for Unit ID 100 is: 12.0.0.100
November, 2008
System Design Considerations 175
Unit ID = 05000032
Convert to Hexadecimal = 4C4B60
Separate into 8 bit sections = 4C, 4B, 60
Each 8 bit section represents 1 octet of the IP address
Convert each section into decimal = 76, 75, 96
Assemble IP address from conversion above = 12.A.B.C where
A = The first 8 bit section in decimal format. In this example, A = 76
B = The second 8 bit section in decimal format. In this example B = 75
C = The third 8 bit section in decimal format. In this example C = 96
The IP address for Unit ID 05000032 is: 12.76.75.96
The MOTOTRBO data applications, both in the radio and externally on the PC, perform this conversion to an IP address when sending and transmitting. Understanding this conversion is important, because it is possible to send traffic directly to the IP address of the radio, though in most cases this happens transparently to the user. For example, if a user creates a text message, and selects a user from the address book with an Individual Radio ID of 12045 (which can be aliased), the text message is sent over the air to radio 12045, and is addressed to IP Address
12.0.47.13. When radio 12045 receives the over-the-air data message, it opens the data message and looks at the target IP address. Because the target IP address matches its own IP, the message is sent to the internal radio application. The target application is dependent on the UDP message and the destination address used at the source.
If the target of a data message is an external PC connected to the MOTOTRBO radio, the sending device will use an IP address with the CAI Network address plus 1. For example, if a MOTOTRBO radio receives a data message for its Radio ID (12045), and the data message inside is targeted towards the address 13.0.47.13, it will forward that message to the connected PC.
For ease of use, the MOTOTRBO radio has the option to be configured with a “Forward to PC” option, which is available in the Network settings of the radio CPS. With this option enabled, all messages targeted to both the 12.x.x.x and 13.x.x.x addresses are routed to the PC. It is recommended that this option be chosen whenever a MOTOTRBO radio is connected to the
Application Server. The “Forward to PC” option also applies to a MOTOTRBO radio (portable or mobile) installed in a mobile environment, i.e. a vehicle, or in a fixed location (a mobile in a tray located on someone’s desk). If a radio is not connected to an external PC, the “Forward to PC” option should be disabled.
It is recommended that the default value of the CAI Network address is used. If this value is changed, all MOTOTRBO radios in the system must be updated with the same CAI Network address. Also available for configuration is the Group CAI Network address. This is used for broadcast data messages. Again, it is recommended that this value remain at its default value.
Figure 4-15 “Air Interface Network Connectivity” displays the IP connectivity with the radio
network. Also included is a simplified Network Address Table (NAT) that shows how the Over-the-
Air traffic is routed to either the Radio or the Mobile Client. The NAT is a translation table within the
MOTOTRBO radio that allows packets to be routed from the PC through the radio and over the air to the destination address. As previously mentioned, when the “Forward to PC” option is selected, traffic for both the 12.x.x.x and 13.x.x.x addresses is forwarded to the PC. If disabled, that NAT
November, 2008
176 System Design Considerations table would show the 12.0.47.13 traffic being routed to Radio IP of 192.168.10.1. This is the common configuration for MOTOTRBO radios that are not connected to an external Mobile Client.
MOTOTRBO Radio
12. 0.47.13
13. 0.47.13
192 .168.10.1
USB
192 .168.10.2
Mobile Client on a PC
12.0.47.13
192 .168.10.1
13.0.47.13
192 .168.10.2
Network Address Translation
Radio ID = 12045
Radio IP = 192.168 .10.1
Accessory IP = 192.168 .10.2
Radio IP Netmask = 255 .255.255 .0
ARS IP = 11.250. 250.250
TMS IP = 11.250 .250.250
Forward to PC Enabled
Figure 4-15 Air Interface Network Connectivity
4.7.1.3 Application Server Control Station Network Connectivity
In some system topologies described in previous sections, the Application Server is required to service up to four different channels. This requires the Application Server to have a network connection of up to four control stations at the same time. Similar to the Mobile Client configuration, when each control station is connected to the Application Server via USB, a network interface is created for each. Each interface is provided the IP address configured as the
Accessory IP in each control station. It is important that the Radio IP and the Accessory IP of the four control stations be different from each other to prevent IP conflict and therefore routing problems in the Application Server. The following IP configuration is recommended:
Control Station 1
Control Station 2
Control Station 3
Control Station 4
Radio IP
192.168.11.1
192.168.12.1
192.168.13.1
192.168.14.1
Accessory IP/PC Network
Interface IP
192.168.11.2
192.168.12.2
192.168.13.2
192.168.14.2
The Individual Radio ID, and therefore the Radio Network IP Address, is very important when configuring the Application Server control stations. Unlike the Radio IP and Accessory IP, the control station’s Radio Network IP should be identical. Each control station should be programmed with the same Radio ID, to enable field radios to communicate with the Application Server regardless of what channel they are on. Although it was mentioned that MOTOTRBO radios should not have duplicate Radio IDs, the control stations are the exception. Because control stations are intended to remain on a single channel, they will always be monitoring the same
November, 2008
System Design Considerations 177 channel. Although this Radio ID of the control stations can be any valid Individual ID, they must be unique, and not duplicate any non-Control Station radio ID. The suggested Radio ID for the
Control Stations is 16448250 which converts to an easy to remember IP address of
12.250.250.250 and 13.250.250.250. Since this Radio ID is so large, it is unlikely to be duplicated on other radios.
It is important to note that every MOTOTRBO radio in the system that is intended to communicate with the Application Server must be programmed with the Application Server control station IP.
This value must be entered for both the Automatic Registration Service (ARS) IP and the Text
Message Server IP, which can be found in the Network settings of the MOTOTRBO radio CPS.
Because the Application Server is the target for these messages, the 13.250.250.250 IP address should be programmed into every field radio. For radios that will use the Mobile Text Messaging
Client application installed on a PC connected to the radio, the 13.250.250.250 IP address should also be programmed into the application.
Application Server
192 .168.11 .2
USB
Control Station
192 .168.11.1
12.250.250 .250
13.250.250 .250
CH1
192.168 .11.1
12.250.250 .250
192.168 .11.2
13.250.250 .250
Network Address Translation
Radio ID = 16448250
Radio IP = 192 .168.11.1
Accessory IP = 192 .168.11.2
Radio IP Netmask = 255.255 .255.0
Forward to PC Enabled
192 .168.12 . 2
USB
Control Station
192 .168.12.1
12.250.250 .250
13.250.250 .250
192.168 .12.1
12.250.250 .250
192.168 .12.2
13.250.250 .250
Network Address Translation
Radio ID = 16448250
Radio IP = 192 .168.12.1
Accessory IP = 192 .168.12.2
Radio IP Netmask = 255.255 .255.0
Forward to PC Enabled
* 16448250
10
= FAFAFA
16
= 250.250 .250
CH2
Figure 4-16 Application Server Control Station Network Connectivity
As previously discussed, the control stations should be configured with the option to “Forward to
PC” so that all data traffic the control station receives is forwarded to the Application Server.
November, 2008
178 System Design Considerations
4.7.1.4 Control Station Considerations
Because the control stations connected to the Application Server act as the data gateway for the system, the control stations themselves do not require an Automatic Registration Service (ARS) IP and the Text Message Server IP to be specified in their CPS Network settings. These fields should be left blank. In addition, the control stations should also have the ARS and GPS options disabled.
These settings are not required for these control stations since they will be not be transmitting their own GPS or ARS anywhere. There is no need for these control stations to be ordered with GPS capability.
Although it is possible to use the control stations connected to the Application Server for voice, it is highly recommended that they only act as data gateways. Since they must remain on a single channel in order to receive the inbound data, it is recommended that they only contain one channel in their channel list and do not have scan enabled. This will guarantee that the Application
Server is always monitoring the correct channel. Since the control stations will only be used for data, there is no need to program any receive or transmit Groups on the channel. In other words, the Contact Name and the Group List can both be set to a value of None. Similarly, it is not necessary to provision any emergency settings either.
It is important to set the TX Preamble duration of the control station to be the same as the other radios in the system. Since most data will be targeted towards these control stations, the proper preamble must be utilized. Use the same guidelines for setting this duration in the control stations as was used in the fielded radios.
The admit criteria of the control station should match the settings which the other radios on the channel are provisioned for. The suggested setting is Color Code Free unless there are analog signals on the channel that the data needs to avoid. If there are analog signals on the channel that the data needs to avoid, then choose Channel Free instead.
When considering other CPS options of the control station, it is a good rule of thumb to minimize the feature options available. This will guarantee that a user cannot accidentally place the control station in a state where it is not monitoring inbound data traffic.
In almost all scenarios, it is highly recommended that a mobile radio with an AC power adapter be utilized as the data gateway. Although a portable radio can temporarily be used for this purpose, it is not recommended for long term installations. The primary reason why a mobile is recommended for this purpose is its ability to remotely locate the RF antenna. This is important since computers and their components are sometimes sensitive to RF power. Mobile antennas should be located away from the server itself and isolated from each other. For example, if a server has four control stations connected to it, it is recommended that the antennas be installed on the roof of the building and separated enough from each other so that they do not interfere. This is also important since in-building coverage is sometimes difficult to achieve. All inbound data messages will pass through these control stations so it is important that they are within good RF coverage of the repeater. Additionally, a control station is left powered on all the time. A portable continuously powered on in a charger is more likely to encounter power related failures.
If a control station does power off or power cycles, host-specific routes will be removed from the
Application Server's routing tables. In these situations, the Application Server to SU data increases the system load as it has to be transmitted by all connected control stations. The actual load increase is based on the amount of Application Server to SU data. This load increase gradually dissipates as the radios re-register with the Presence Notifier and the host-specific routes are added back into the routing table. However, it is recommended to connect control
November, 2008
System Design Considerations 179 stations to an Uninterrupted Power Supply (UPS) and are never powered off and on while radios are registered with the Presence Notifier.
During the registration process with the Presence Notifier, the SU is instructed to refresh its registration at a specific time interval. The default time interval is 4 hours, though this is a configurable parameter in the Presence Notifier. If the time interval is decreased, more registration messages are sent to keep the presence availability information fresh but the system load is increased. If this time interval is increased, the system load is decreased but the presence availability information may become stale.
Once a radio is registered with the Presence Notifier, the MCDD adds a route to a routing table, so data messages from the Application Server to the SU are transmitted on the correct channel.
However, if for some reason the host-specific route does not exist, then the Global Route is used and the data message will be transmitted from all control stations connected to the Application
Server. This scenario increases system loading during situations where there is Application Server to SU data. An example of this would be network (Text Message Server) sourced text messages targeted towards subscribers in the field.
4.7.1.5 Multi-Channel Device Driver (MCDD) and Required Static Routes
As described above, the Application Server can have up to four different network interfaces that access the radio network. In order for data messages targeted towards Radio Network IP addresses, such as 12.0.0.1 and 12.0.47.13, to transmit out through a network interface with IP addresses 192.168.11.2 or 192.168.12.2, the MCDD is required to add routes for each radio that registers with the Presence Notifier. For example, when radio 12045 transmits a registration message to its programmed ARS IP address (e.g. 12.0.47.13) on one of the channels monitored by a control station, the control station forwards that address to the Application Server through its network interface (e.g. 192.168.11.2). The MCDD then automatically adds a route for that radio IP
(12.0.47.13 and 13.0.47.13) to the 192.168.11.2 network interface. Once that is done, if a message from the Application Server needs to reach 12.0.47.13 or 13.0.47.13, the message is routed to the 192.168.11.2 network interface, and therefore out the correct control station and correct channel that has registered radio 12045. This is how data messages are sent out on the correct channel for a radio.
Additional steps are required to route multicast traffic. Multicast traffic is traffic destined for radio groups. The routing table in the PC must be modified to allow for multicast traffic. Please see the
MCDD install manual for details.
4.7.1.6 Application Server and Dispatcher Network Connectivity
As described in previous chapters, the Application Server can also be configured with a LAN connection to the Customer Enterprise Network (CEN). A few restrictions apply to the network configuration between the Application Server and the Dispatch clients. In most customer cases, the LAN interface on the Application Server is connected to their pre-existing network. The only requirement is that the assigned IP of the LAN network interface must not conflict with those assigned to the Network Interfaces of the Control Stations. Additionally, the Application
Dispatchers (such as Location Dispatch or Text Message Dispatch) must be connected through the customer CEN to the Application Server. In order for the Text Message Server to forward email text messages, the Application Server must be connected to the Internet. If the network is configured to operate with a firewall, the programmed ports for the applications should be opened and allowed. Details of this configuration can be found in the Text Message and Location application install guides.
November, 2008
180 System Design Considerations
4.7.1.7 MOTOTRBO Subject Line Usage
A MOTOTRBO Text Message is comprised of three parts: A subject line, subject line delimiter and body. The subject line delimiter is a carriage return (Unicode code point U+000D) and line feed
(Unicode code point U+000A) character pair (CRLF). Therefore, anything up to the first CRLF within the Message is interpreted as the subject line and anything after the first CRLF is interpreted as the body. The subject line is left blank if there are no characters before the first
CRLF, or if no CRLF pairs are contained in the Message.
When e-mail text messages are received by the Application Server the e-mail subject line and body are converted into the MOTOTRBO Text Message subject line and body respectively.
The maximum length of a MOTOTRBO Text Message is technically 140 characters according to the protocol. However, applications that support the use of Subject Lines may reduce the number of the effective payload. The Customer Programming Software (CPS) and the applications in the radios that create text messages will limit the effective payload to 138 characters. External applications that run on Personal Computers (PC) may further reduce the effective payload to provide indications that messages have been truncated (for example replacing the last character with a horizontal ellipse character '…'). E-mails that are longer than 138 characters will be truncated to fit. For example, if an e-mail is received with a 200 character subject line and a 300 character body only the first 137 characters of the subject line plus a horizontal ellipse '…' at the end is converted into the MOTOTRBO Text Message and the rest of the e-mail will be discarded.
In another example, if an e-mail is received with a 100 character subject line and a 300 character body, then the 100 characters of the subject line and the first 37 characters of the body with an ellipse added at the end will be converted into the MOTOTRBO Text Message format.
Radios replying to messages preserve the original message's subject line. In this manner, external services and solutions that use e-mail for communication can use the content of the subject line to correlate between e-mails that are sent and e-mails that are received. For example, an automated service could send out an e-mail with a unique ID string in the subject line. If a radio replies to the message, it preserves the subject line with the unique ID string and the automated system can use the address and subject line of the message to know that a specific unit had replied to a specific message.
The number of characters allowed in a reply by a radio are equal to 138 characters minus the number of characters in the subject line. For example, if an e-mail is sent with a 30 character subject line and a 100 character body, the entire message will be received by the radio. When the radio replies to the message the subject line is automatically preserved leaving 108 characters for the radio to reply with.
MOTOTRBO Text Messages that originate from the front panel of radios or the Text Messaging
Client via the Application Server and destined for e-mails addresses will contain blank subject lines. Radios do not have the capability to create or modify a subject line from the front panel. The
CPS does not have the capability to create a subject line.
4.7.1.8 MOTOTRBO Example System IP Plan
The following diagram is a summary of the information contained in the previous sections. It should be used as a guideline for configuring a MOTOTRBO System.
November, 2008
System Design Considerations 181 nI (E-mail)
November, 2008
182 System Design Considerations
4.7.1.9 Application Server Network Connection Considerations
Besides being connected to the radio network via the control station(s), the Application Server may also be connected to another network such as the Internet. When operating under these conditions, it is important to consider the following:
• Disable all protocol support except for TCP/IP.
• Ensure networking application messages are routed to the Ethernet connector or the wireless network interface and not to the network connection to the control station(s).
Sometimes, the Application Server is connected to the radio network via the control station(s).
When operating under these conditions, it is important to remember that all network traffic generated by the Application Server will be routed to the control station(s). In order to optimize the radio network, these messages should be kept to a minimum. The following items should minimize the amount of network traffic being routed to the control station(s).
• Disable all protocol support except for TCP/IP.
• Turn off the PC wireless network interface.
• Do not launch any networking application (i.e. internet browser, e-mail, etc.).
• Disable all automatic updates for network applications that are running in the background, such as virus updates, IM updates, Windows updates, etc.
4.7.2 Mobile Terminal and Application Server
Power Management Considerations
There are some considerations that have to be taken with regards to the Power Management settings on a PC being used for either a Mobile Terminal or Application Server.
It is recommended that the power management settings of the Application Server and Mobile
Client be disabled. Specifically the System Standby and System Hibernation settings should be set to Never.
It is crucial that the Application Server and Mobile Terminal always be active so that they can transmit and receive data messages. If the Application Server or Mobile Client is allowed to enter
System Standby or System Hibernation, it will not respond to received data messages. The radio(s) connected to the Application Server or Mobile Client will then queue the data until messages fail to be delivered. It will be the responsibility of the sending device to retry the failed message. A user will need to “awaken” the Application Server or Mobile Client before it will accept messages again.
4.8 Customer Fleetmap Development
In a MOTOTRBO system, the system administrator can maximize the system's communication effectiveness by translating their organization's operation requirements into a list of supported features. The result of identifying and formalizing this information is often referred to as fleetmapping.
Fleetmapping can be thought of as:
November, 2008
System Design Considerations 183
• Assigning groups to the radios issued to personnel.
• Assigning groups to the dispatcher control positions.
• Assigning groups to channels and slots.
• Defining the feature subsets available to the personnel using the radios and dispatcher control positions.
A fleetmap determines how the radio communications for each user group of an organization is controlled. Through controlling communications between different user groups and between individuals within a group, the organization can manage the radio communications system resources efficiently. Fleetmapping also provides a structured approach to the management of a large number of radio users, and provides the opportunity to plan in advance for expansion or changes within an organization.
Some of the factors that should be considered when creating or planning changes to the fleetmap are:
• Identifying a functional fleetmap design team
• Identifying radio users
• Organizing radio users into groups
• Assigning IDs and aliases
• Determining feature assignments:
• Private Calls
• All Call
• PTT ID and Aliasing
• Radio Disable
• Remote Monitor
• Radio Check
• Call Alert
• Emergency Configurations
• Determining channel access requirements
• Determining subscriber programming requirements
• Determining data application access and requirements
4.8.1 Identifying a Functional Fleetmap Design Team
To develop a fleetmap, a design team of key representatives from the customer’s system managers, technicians, and operators needs to be formed to create effective communications plans for radio users and system operators.
4.8.2 Identifying Radio Users
The system administrator needs to do the following to establish a fleetmap.
• Determine the customer’s organizational structure from a radio user’s perspective
• Consider the needs of portable and mobile radio users
November, 2008
184 System Design Considerations
• List all of the potential radio users in a single column on a spreadsheet
• Define the functional groups that use the system
• Group together radio users who need to communicate with each other on a regular basis
Typically, each functional group of radios will have different communication requirements.
Therefore, each functional group will have their own codeplug for their radios that differs from other functional groups.
Codeplug construction.ctb
security.ctb
administrative.ctb
transport.ctb
Functional
Group
Construction
User
Name
John
Construction
Construction
Security
Security
Bob
Rick
Al
Joe
Administrative Frank
Administrative Mike
Administrative Steve
Transport
Transport
Lenny
Carl
Alias
User
ID
Talks with
Listens only to
John
Bob
Rick
Al
1873
1835
542
98
Construction,
Transport
Construction,
Transport
Construction,
Transport
Security,
Administrative
Security
Security
Security
-
Joe
Frank
4762
6654
Security,
Administrative
Administrative,
Security
-
-
Mike 19172 Administrative,
Security
Steve 78378 Administrative,
Security
Lenny 23
-
-
Security
Carl 2
Transport,
Construction
Transport,
Construction
Security
4.8.3 Organizing Radio Users into Groups
Once you have identified all of the individual users, associate them with groups. The communication requirements for one group may differ with the requirements of another group.
Certain groups may need to communicate with multiple groups, in addition to their primary group.
Therefore, you will need to identify the individual radios and the corresponding groups that they need to communicate with. Also note that the group organization may be different from the organization’s formal reporting structure.
You will also need to determine the traffic patterns of the individual users and functional groups, so
that channel, slot and group assignments can be associated with each user. “Digital Repeater
Loading” on page 146 should provide information to help decide the distribution of groups, logical
channel assignments (slots) and physical channel assignments.
November, 2008
System Design Considerations 185
When organizing your MOTOTRBO system, remember that individual users, radios, and groups all have different requirements. Subsequently, they also have different parameters associated with them. Organize the radios, groups and slot assignments in a spreadsheet. An example is shown below.
Functional group and talkgroup mapping
Construction Security
TG ID: 62 TG ID: 54 TG ID: 46 TG ID: 8766 TG ID: 123
Administrative
TG ID: 99
Transport
TG ID: 997 TG ID: 368
File codeplug as Functional group User name construction.ctb
security.ctb
administrative.ctb
transport.ctb
Construction
Construction
Construction
Security
Security
Administrative
Administrative
Administrative
Transport
Transport
John
Bob
Rick
Al
Joe
Frank
Mike
Steve
Kenny
Carl
Alias
John
Bob
Rick
Al
Joe
Frank
Mike
Steve
Kenny
Carl
User ID
Talks with functional groups
Listens only to functional groups
1873
1835
Construction,
Transport
Construction,
Transport
Security
Security
542
98
4762
6654
Construction,
Transport
Security,
Administrative
Security,
Administrative
Administrative,
Security
Security
-
-
-
19172
78378
23
2
Administrative,
Security
Administrative,
Security
Transport,
Construction
Transport,
Construction
-
-
Security
Security ch 1 - slot 1 ch 2 - slot 1 ch 2 - slot 1 ch 2 - slot 1 ch 1 - slot 1 ch 2 - slot 1 ch 1 - slot 1 ch 2 - slot 1 x x x x x x x x x x x x x x x x x x x x x x x x x x
4.8.3.1 Configuration of Groups
In MOTOTRBO systems, capabilities for Group Calls are configured via the subscriber (portable and mobile) CPS. The repeater does not require any specific configuration with respect to groups.
There are three interrelated steps in configuring your radios to participate in group calls; it is configured through the “Contacts”, “RX Group Lists” and “Channels” menu folders in CPS. While the MOTOTRBO CPS enables great flexibility in configuring your system for Group calling, one basic procedure is as follows:
1. In the “Contacts” folder, go to the “Digital” folder, and add a call of type “Group Call.” The
CPS will provide a default name and ID; you will need to assign a unique ID between 1 and 16776415, and should also rename the group call to an intuitive alphanumeric name representative of the user workgroup that will ultimately be using this group, e.g. “Maintenance.” All calls created in the “Contacts” folder appear in the “Contacts” menu of the subscriber by name, and the Group name also appears on the radio display when a group call is received. In step 3 below, you will assign this group call, again by name, to the Transmit
(TX) “Contact Name” attribute of a channel.
November, 2008
186 System Design Considerations
2. In the “RX Group Lists” folder, add a new group list, and then add the Group Call you just created to be a member of the list. The group list controls which groups a radio will hear when tuned to a selected channel. For example, if members of the Maintenance group should also be able to listen to other groups on the channel, those other groups would be added to the RX Group List; if members of the Maintenance group should only hear traffic related to their own group, then only the Maintenance group would be added to the group list. The group list should again be renamed to something intuitive; in step 3 below you will assign this group list, by name, to the RX Group List attribute of a channel.
3. In the channels menu, each “zone” can contain up to 16 channels that can be mapped to the 16-position top selector knob of the portable radio or the relative channel number selections on a mobile. Radio users that require more than 16 channels must organize them into multiple folders in CPS, so that they can be accessed as “zones” in the radio menu. Zones, if used, can and should also be given names. In an appropriate folder, create a new digital channel. To fully define the channel, you must assign the appropriate receive and transmit frequencies, and also select the TDMA slot number. Then, add the group list you defined in step 2 above to the RX Group List attribute, followed by adding the digital group call to the TX Contact Name attribute. You will also need to define the TX
Admit Criteria. Rename the channel to something intuitive, and assign it to a knob position; the channel name will be displayed on the radio whenever it is selected via the top knob on a portable or the up/down channel selection buttons on a mobile.
If configured as described above, radio users are able to place a group call simply by selecting the defined channel and pressing PTT. Groups can also be selected from the Contacts menu on display radios, as enabled by step one of the above. It is also possible to assign a group call to a radio programmable button (called a “one touch call” in CPS) so that users can place a group call at the touch of a button.
4.8.4 Assigning IDs and Aliases
Each radio, group, and control station in the system must have a unique ID number and alias.
There should be no duplicate IDs on the system.
4.8.4.1 Identifying Radio IDs
Radio IDs for a MOTOTRBO system range between 1 and 16776415. There are two approaches to identifying radio IDs:
Option A:
As a general practice, create contiguous ID ranges, but allow room for future expansion. As an example, a department has a current requirement for 1200 IDs. However, the department may need up to 2000 IDs in 12 months. Assigning the IDs during planning saves future re-programming of radios and subscriber records.
November, 2008
System Design Considerations 187
Option B:
The radio ID can be created so that each ID will provide certain information about the radio. Each digit in the Radio ID can represent a certain code or radio type. For example:
16776415
Range 0-9999.Sequence Number
Range 0-6. 0 - Reserved
1- MOTOTRBO Portable
2 - MOTOTRBO Mobile
3 - Analog Portable
4 - Analog Mobile
5 - Reserved
Other options are to use a digit to identify the user’s home group or other identifier. Radio IDs are not centrally maintained or managed in a MOTOTRBO system. It is up to the system administrator to document the radio ID designation. Note that these IDs must match those entered in other radios and data applications in order for the system to operate correctly.
4.8.4.2 Assigning Radio Aliases
You can assign an alias to each radio user. Although anything can be used as an alias, the user’s last name is often used. Radios that are assigned to vehicles are often aliased with the vehicle number such as “Cab 35” or “Fire Truck 3.” If radios are used by multiple users through different shifts, the job description is often used such as “West Side Guard” or “Cleaning Crew 2.” Since unique names are required, no two radio users should have the same alias. Aliases should be consistent in all radio programming (CPS), and the data applications. Databases are not shared between the various applications. There is no centralized database in MOTOTRBO. Since aliasing is done independently on each device, if the alias and ID do not match in each device in the system, customers may become confused.
November, 2008
188 System Design Considerations
An example of a spreadsheet showing a possible radio ID and alias database is shown below:
Functional
Group
User
Name
Construction
Construction
Construction
Security
John
Bob
Rick
Al
Security Joe
Administrative Frank
Administrative Mike
Administrative Steve
Transport
Transport
Lenny
Carl
Alias
John
Bob
Rick
Al
Joe
Frank
Mike
Steve
Lenny
Carl
Unit ID
1873
1835
542
98
4762
6654
19172
78378
23
2
Talks with
Listens only to
Construction, Transport Security
Construction, Transport Security
Construction, Transport Security
Security, Administrative -
Security, Administrative
Administrative, Security
Administrative, Security
Administrative, Security
Transport, Construction Security
Transport, Construction Security
-
-
-
-
4.8.4.3 Identifying Group IDs
Group IDs for a MOTOTRBO system range between 1 and 16776415. The same approach that is used to identify radio IDs can be used for Group IDs. Group IDs are not centrally maintained or managed in a MOTOTRBO system. It is up to the system administrator to document the Group designation. Note that these IDs must match those entered in other radios and data applications in order for the system to operate correctly.
4.8.4.4 Assigning Group Aliases
The groups should also be consistent throughout the system. Display radios and data applications identify groups by alias. Groups should be named with an alias the customer will easily understand. Highly abstract names often cause confusion. When assigning aliases, you will need to consider character and subscriber limitations. Some radio models may allow more or fewer characters than the data applications. Since aliasing is done independently in each device, if the alias and ID do not match in each device in the system, customers may become confused. An example is shown below:
Construction
Functional group and talkgroup mapping
Security Administrative
TG ID: 62 TG ID: 54 TG ID: 46 TG ID: 8766 TG ID: 123 TG ID: 99
Transport
TG ID: 997 TG ID: 368
November, 2008 ch 1 - slot 1 ch 2 - slot 1 ch 2 - slot 1 ch 2 - slot 1 ch 1 - slot 1 ch 2 - slot 1 ch 1 - slot 1 ch 2 - slot 1
System Design Considerations 189
4.8.5 Determining Which Channel Operates in
Repeater Mode or Direct Mode
Repeater Mode enables unit-to-unit communications using the repeater. Direct Mode enables unitto-unit communications without using the repeater. Each channel on the radio is programmed to be either a Direct Mode channel or a Repeater Mode channel via the CPS.
Channels defined as Repeater channels in the CPS can be toggled to operate in Talkaround mode via user selection from the menu or a programmable button. When this happens, the transmit frequency is set equal to the receive frequency, and this channel effectively performs like a Direct
Mode channel.
4.8.6 Determining Feature Assignments
4.8.6.1 Determining Supervisor Radios
Supervisor radios are not defined in the CPS by any specific “Supervisor” option.Instead they are subscribers that have supervisory options enabled. Supervisor radios are responsible for acknowledging emergency calls and alarms, and also perform administrative duties such as remote monitor and selective radio inhibit. Some features should only be allowed to users that can use them responsibly.
4.8.6.2 Private Calls
In MOTOTRBO systems, capabilities for Private Calls are configured via the subscriber (portable and mobile) CPS. The repeater does not require any specific configuration with respect to Private calls. While the MOTOTRBO CPS enables great flexibility in configuring your system for Private calling, one basic procedure is as follows:
1. Every MOTOTRBO radio in a system should be assigned a unique radio ID in the CPS.
This parameter is programmed in the Radio ID field under the General Settings menu.
2. In the “Contacts” folder, go to the “Digital” folder, and add a call of type “Private Call.” The
CPS will provide a default name and ID; assign the actual radio ID of the radio that is to be privately called to this field, and rename the call to an intuitive alphanumeric name (representative of the radio that to be addressed). Note that all calls created in the “Contacts” folder appear in the “Contacts” menu of the subscriber by name, and this name also appears on the radio display when a private call is received.
If configured as above, radio users are able to make Private Calls by selecting the private call, by name, from the radio’s Contacts menu. In addition, similar to assigning a group call to a channel as described above, it is also possible to assign a private call to the TX Contact Name attribute of a channel, so that users can place private calls by making the appropriate channel selection via the top knob on a portable or up/down channel select buttons on a mobile. It is also possible to assign a private call to a radio programmable button (called a “one touch call” in CPS) so that users can place a private call at the touch of a button. These latter 2 methods are the only methods for nondisplay radios to place private calls.
Please note that a radio can, in practice, receive a private call from any other radio that is available on the channel, regardless of whether the receiving radio has created a CPS private call entry for that radio. The receiving radio will in this case display the radio ID of the calling radio, rather than
November, 2008
190 System Design Considerations an alphanumeric alias. Similarly, a radio can place a private call to any other radio by utilizing the
“manual dialing” option in the radio’s menu, however in this case the user must know the Radio ID of the called party.
4.8.6.3 All Call
In MOTOTRBO systems, capabilities for All Calls are configured via the subscriber (portable and mobile) CPS. The repeater does not require any specific configuration with respect to All Calls.
While the MOTOTRBO CPS enables great flexibility in configuring a system for All Calls, one basic procedure is as follows:
1. In the “Contacts” folder, go to the “Digital” folder, and add a call of type “All Call.” The CPS will provide a default name; rename the call to an intuitive alphanumeric name representative of the All Call. All calls created in the “Contacts” folder appear in the “Contacts” menu of the subscriber by name.
If configured as above, a user would initiate an All Call by selecting the call, by name, from the radio’s Contacts menu. Additionally, similar to assigning a group call to a channel as described above, it is also possible to assign an All Call to the TX Contact Name attribute of a channel, so that users can place All Calls by making the appropriate channel selection via the top knob on a portable or up/down channel select buttons on a mobile. It is also possible to assign an All Call to a radio programmable button (called a “one touch call” in CPS), so that users can place an All Call at the touch of a button. These latter 2 methods are the only methods for non-display radios to place All Calls.
Since All Calls are monitored by everyone on a slot, it is suggested that only supervisors be granted the ability to transmit All Calls.
4.8.6.4 Radio Disable
In MOTOTRBO systems, Radio Disable is configured in the portable and mobile radio CPS. To allow a radio the ability to initiate this function, this option must be enabled in the CPS “Menu” settings. To permit (or prevent) a given radio from decoding and responding to this command, this option must be configured in the CPS “signaling systems” settings.
Since the ability to disable a user could be misused, it is suggested that only supervisors be granted the ability to initiate a Radio Disable.
4.8.6.5 Remote Monitor
In MOTOTRBO systems, Remote Monitor is configured in the portable and mobile radio CPS. To allow a radio the ability to initiate this function, this option must be enabled in the CPS “Menu” settings. To permit (or prevent) a given radio from decoding and responding to this command, this option must be configured in the CPS “signaling systems” settings. If a radio is configured to decode the remote monitor command, the duration that the target radio will transmit after receiving a Remote Monitor command can be set in the CPS “signaling systems” settings of the target radio.
Since the ability to remotely monitor a user could be misused, it is suggested that only supervisors be granted the ability to initiate a Remote Monitor.
November, 2008
System Design Considerations 191
4.8.6.6 Radio Check
In MOTOTRBO systems, Radio Check is configured in the portable and mobile radio CPS. To allow a radio the ability to initiate this function, this option must be enabled in the CPS “Menu” settings. All MOTOTRBO radios decode and respond to a Radio Check.
4.8.6.7 Call Alert
In MOTOTRBO systems, Call Alert is configured in the portable and mobile radio CPS. To allow a radio the ability to initiate this function, this option must be enabled in the CPS “Menu” settings. All
MOTOTRBO radios decode and respond to a Call Alert.
4.8.7 Emergency Handling Configuration
Configuring a communication system (like MOTOTRBO) to handle emergency situations requires some up front design. In emergency situations, it is ideal that when a user initiates an emergency, he is immediately routed to someone who can handle his emergency situation. The previous sections have addressed some basic feature descriptions of how emergency can operate. This section will outline in detail how to program the numerous devices in the system in order to meet the needs of a customer’s emergency needs and also provide some guidance on choosing the available options. It is recommended to review the Emergency Handling feature explanation in the earlier chapters.
It is important when creating an emergency handling plan to understand the customer’s existing emergency procedures. An interview with a representative in charge of emergency operations is usually required to fully understand the process. This information will act as a base for selecting a configuration.
4.8.7.1 Emergency Handling User Roles
The first step is identifying users that will participate in the emergency handling plan. There are three major roles to identify: Emergency Initiator, Monitoring Supervisor, and Acknowledging
Supervisor.
An Emergency Initiator is a user that does not necessarily have any responsibility for handling emergencies, but is expected, at some point to have an emergency that needs handling. This user’s radio is configured with either an emergency button or an external switch to initiate an emergency. The radio needs to be programmed on how to contact a Supervisor based on the selected configuration. Alternatively, this radio can be programmed to give a non-persistent indication (display and/or audio) that the current call is an Emergency Call. This indicates to the user that he should avoid interfering with the call taking place. The majority of users in a system will be considered Emergency Initiators.
A Monitoring Supervisor is a user that needs to know when an emergency occurs, but is not the individual identified to handle and acknowledge emergencies. This user’s radio will provide an indication that an Emergency Alarm has been received and provide an indication that an
Emergency Call is taking place. This user does not transmit an acknowledgement to the
Emergency Alarm. The Emergency Alarm will be persistent on the Monitoring Supervisor’s radio until manually cleared. Duplicate attempts of the same Emergency Alarm will not restart the
Emergency indication. There can be multiple Monitoring Supervisors per group. A Monitoring
Supervisor may also be an Emergency Initiator.
November, 2008
192 System Design Considerations
An Acknowledging Supervisor is the user specifically identified to respond to received emergency situations. This user’s radio provides an indication that an Emergency Alarm has been received, and provides an indication that an Emergency Call is taking place. In addition to the indications, this user’s radio is responsible for transmitting an acknowledgement to the Emergency Initiator.
Until the Emergency Initiator receives the acknowledgement, his radio will continue to transmit its emergency alarm messages, until his user takes action to stop or the radio exhausts the number of programmed retries. It is important to note that the Acknowledging Supervisor’s radio (not the user) sends the acknowledgement, when it receives the Emergency Alarm. Reception of an emergency alarm acknowledgement only guarantees that the radio received the message, not the user. Because it is the responsibility of the Acknowledging Supervisor to stop the Emergency
Initiator’s retries, duplicate attempts of the same Emergency Alarm will restart the emergency indication if cleared. It is highly recommended that there only be one Acknowledging Supervisor per group and slot. If there is more than one, acknowledgement messages may interfere with each other when transmitting, and cause a delay in acknowledging the Emergency Initiator. An
Acknowledging Supervisor may also be an Emergency Initiator.
These MOTOTRBO radios are configured to operate in each role by setting a few options using the CPS, as described in the following table. Note that these options are configurable per channel, and therefore per Group, Frequency and Slot. This means that a user can play a different role depending on the channel he has selected. He may be an Acknowledging Supervisor for one
Group, but only an Emergency Initiator on another. Note that the selected Digital System references a group of parameters used, when a user initiates an emergency. A radio programmed with a Digital Emergency System of None will not be able to initiate an emergency on that channel.
The parameters contained within the digital system will be discussed in detail later.
Emergency
Handling Role
Emergency Initiator
Monitoring Supervisor
Acknowledging
Supervisor
Digital
Emergency
System
Selected
CPS Option per Channel
Emergency
Alarm
Indication
Disabled
Emergency
Alarm Ack
Disabled
Enabled Disabled
Emergency
Call
Indication
Optionally
Enabled
Enabled Selected Or
None
Selected Or
None
Enabled Enabled Enabled
By identifying the roles in the customer’s organization, it should start to become clear how they handle emergencies at a high level. If there are numerous supervisors, it is important to note which groups these supervisors monitor, as there may be more than one supervisor that monitors multiple or all the groups. This will be the key to deciding on an emergency handling strategy.
4.8.7.2 Emergency Handling Strategies
There are two major strategies to handle emergency situations: Tactical or Centralized.
A Tactical emergency handling strategy is when the Emergency Initiators transmit their emergency alarm and call on the channel, group and slot they are currently selected on. This assumes that there is an Acknowledging Supervisor that is monitoring that same channel, group or slot. This
November, 2008
System Design Considerations 193 means that each group is required to have a designated supervisor whose responsibility is to handle emergency situations. Because emergency alarms do not traverse slots or channels, there would need to be one (and only one) supervisor designated for each group on every channel and slot. Multiple Monitoring Supervisors could be configured to monitor for emergency alarms without sending acknowledgements to stop the Emergency Initiator’s retries. It is also very important to note that because users are generally mobile it is possible that the Acknowledging Supervisor becomes unavailable, busy, changes channels, or roams out of range of the system. If this happens, Emergency Initiators may go unacknowledged.
In a system with a small number of users and groups, a Tactical strategy is often the easiest method to implement. When the number of users, groups, and channels grow, the required number of Acknowledging Supervisor also grows. It will quickly become difficult to guarantee the multiple assigned Acknowledging Supervisors are actively monitoring their assigned groups. It is also often not cost effective to have numerous designated Acknowledging Supervisors handling emergency situations.
In order to operate Tactically, the Emergency Initiator needs to be on a channel that is configured with a Digital Emergency System, and has its Emergency Revert Channel set to “Selected” in the
CPS. Since this is set on a per channel basis, a radio could be configured to operate differently based on the selected channel.
A Centralized emergency strategy is when the Emergency Initiators transmit their emergency alarm and call on a dedicated channel, group or slot. This strategy is often referred to as a “revert” strategy. This strategy assumes that there is one dedicated Acknowledging Supervisor whose job is to handle the emergencies of all users in the system, and that the Emergency Initiators automatically change or “revert” to the channel the Acknowledging Supervisor is operating on to process their emergency. Because this Acknowledging Supervisor’s role is only to monitor for emergencies, it becomes easier to manage his availability. Further steps can be taken to guarantee the availability of the Acknowledging Supervisor. It is a good idea to locate the
Acknowledging Supervisor’s radio in a good RF coverage area of the system, so not to go out of range. Having a designated RF channel and slot that is specifically used for managing emergencies, lowers the possibility of encountering a busy system when there is heavy emergency traffic.
In larger systems the Acknowledging Supervisor’s role in a centralized configuration is often referred to a Dispatcher. It is not expected that this Acknowledging Supervisor will leave his location and actually resolve the emergency himself. His role is to contact and dispatch other resources to handle the emergency that was reported. The Acknowledging Supervisor is able to switch channels to dispatch assistance to the Emergency Initiator, and then switch back to the emergency channel.
In some cases multiple Centralized configurations may be required. This is often needed when the number of users becomes too much for one Acknowledging Supervisor to handle, or if the customer’s organization is broken into multiple organizations that have their own Acknowledging
Supervisor. This may also be required if a system contains multiple repeaters with nonoverlapping RF coverage. While operating on one site, a radio may not be in range of another site, therefore if he were to revert to the other site to process an emergency, he may not be in the coverage range of the repeater to complete the transmission. In this scenario, it is recommended that an Acknowledging Supervisor be designated for each RF coverage range. This would require a radio be configured to revert to channels within RF coverage of the selected channel.
In order to revert to a Centralized channel, the Emergency Initiator needs to select the channel that is configured with a Digital Emergency System, and has its Emergency Revert Channel set to the designated Emergency Channel in the CPS. Since this is configured on a per channel basis, a
November, 2008
194 System Design Considerations radio could be configured to operate differently based on the selected channel. There are four
Digital Emergency Systems available. This means that one radio can be configured to revert to four different channels, depending on the configuration of the Digital Emergency System that is assigned to the selected channel.
It is not recommended that a Centralized emergency strategy be implemented using Emergency
Initiators operating Tactically and one Acknowledging Supervisor scanning multiple channels.
When multiple emergencies occur simultaneously it is more effective for the Emergency Initiators to come to the Acknowledging Supervisor rather the Acknowledging Supervisor searching for the
Emergency Initiators.
4.8.7.3 Acknowledging Supervisors in Emergency
The emergency strategy of the Acknowledging Supervisor himself should be considered. Since this user is the one identified to handle emergencies, who should he attempt to contact if he has an emergency. In a tactical environment, the user may only need to change or possible “revert” to another channel to contact another Acknowledging Supervisor. In a centralized configuration with multiple dispatchers, one Acknowledging Supervisor dispatcher could be configured to revert to the other Acknowledging Supervisor dispatcher. If there is no other individual to contact, the
Acknowledging Supervisor may simply wish to operate tactically, and transmit his emergency on the selected channel so that the Monitoring Supervisors can be contacted.
4.8.7.4 Extended Emergency Call Hang time
As previously described, the MOTOTRBO repeater reserves the channel for a short duration after a voice transmission. By default the call hang time associated with an emergency is slightly larger than those for group calls and private calls. The repeater can be configured to extend the call hang time for Emergency Calls even longer to provide an additional opportunity for the Emergency
Initiator or Emergency Acknowledger to communicate without competing with other users.
4.8.7.5 Emergency Revert and GPS Revert Considerations
During registration with the Location Server the SU receives a periodic location update request and an emergency location update request. When the SU enters the emergency state it will attempt to transmit the emergency location update response on a specific channel. The transmission channel of this message is defined by the radio’s Emergency Mode (Emergency
Alarm, Emergency Alarm with Call or Emergency Alarm with Voice to Follow) and its GPS
Transmission Channel (Selected or Revert). Understanding which channel is used for the
Emergency Location Update is important, as a control station is required on that channel to enable the reception of the message by the application server. For more information on emergency
handling, see See “Emergency Handling Strategies” on page 192.
The following sections define how Emergency Revert and GPS Revert interact when the
Emergency Revert Channel contains a GPS Revert Channel and the SU received a Emergency
Location Update Request on the Selected Channel. These are sample scenarios intended to aid in understanding the interactions. The following sections use a direct mode configuration to simplify the diagrams, though they can also be applied to repeater mode. The SU initiating the emergency has been configured with the following channels; GROUP1, LOCATION 1, EMERGENCY and
November, 2008
System Design Considerations 195
LOCATION2. The TX/RX frequency, the GPS Transmission Channel and the Emergency Revert
Channel for each of the four configured channels are listed in the table below.
GROUP 1 LOCATION 1 EMERGENCY LOCATION 2
Transmit/Receive
Frequencies
GPS Transmission
Channel
Emergency Revert
Channel
F1
LOCATION 1
EMERGENCY
F2
None
None
F3
LOCATION 2
None
F4
None
None
4.8.7.5.1 Emergency Alarm
TX=f
1
RX=f
1
USB f
1
Presence f
1
Location Request f
1
GPS
MOTOTRBO
Control Station
(digital mode)
TX=f
2
RX=f
2
Location
Response f
2
MOTOTRBO SU
(digital mode)
2
USB
1
MOTOTRBO
Control Station
(digital mode)
MOTOTRBO SU
(digital mode)
MCDD
Presence Notifier
Location Server
Application Server
Figure 4-18 Emergency Alarm and GPS Revert Interaction Diagram
Figure 4-18 “Emergency Alarm and GPS Revert Interaction Diagram” illustrates the channels used
when an emergency is initiated and the SU is configured for Emergency Alarm Only with an
Emergency Revert Channel and the Emergency Revert Channel is configured with a GPS Revert
November, 2008
196 System Design Considerations
Channel. (Note: The channels are defined in the table in the previous section). The following describes the sequence of events.
1. The SU switches from the Selected Channel, f1, to the Emergency Revert Channel, f3.
From here the SU transmits the Emergency Alarm and waits for the acknowledgement.
While waiting for the acknowledgement, the Emergency Location Update is held in queue.
2. Once the acknowledgement is received the SU switches back to the selected channel, f1, and transmits the Emergency Location Update.
Therefore, in this scenario the GPS Revert Channel associated with the Emergency Revert
Channel has no impact on the channel used to transmit the Emergency Location Update.
4.8.7.5.2 Emergency Alarm and Call
TX=f
RX=f
1
1 f
1
Presence f
1
Location Request GPS f
3
Presence (Emg.) f
3
Location Request (Emg.)
3
TX=f
RX=f
USB USB f
1 f
3
TX=f
2
RX=f
2
MOTOTRBO
Control Station
(digital mode)
Location
Response f
2
MOTOTRBO SU
(digital mode)
Locat ion
Respon f
4
MOTOTRBO
Control Station se
(Em g.)
(digital mode)
TX=f
4
RX=f
4
2
3
3
USB
1
4 USB
MOTOTRBO
Control Station
(digital mode)
MOTOTRBO SU
(digital mode)
MOTOTRBO
Control Station
(digital mode)
MCDD
Presence Notifier
Location Server
Application Server
Figure 4-19 Emergency Alarm and Call and GPS Interaction Diagram
Figure 4-19 “Emergency Alarm and Call and GPS Interaction Diagram” illustrates the channels
used when an emergency is initiated and the SU is configured for Emergency Alarm and Call with an Emergency Revert Channel and the Emergency Revert Channel is configured with a GPS
Revert Channel. (Note: The channels are defined in the table in the previous section) The following describes the sequence of events.
November, 2008
System Design Considerations 197
1. The SU switches from the Selected Channel, f1, to the Emergency Revert Channel, f3.
From here the SU transmits the Emergency Alarm and waits for the acknowledgement.
While waiting for the acknowledgement, the Emergency Location Update is held in queue.
2. Once the acknowledgement is received, the SU switches to the Emergency Revert’s GPS
Revert Channel, f4, and then transmits the Emergency Location Update.
3. After this transmission, the SU switches to the Emergency Revert Channel, f3, and while not being involved in voice calls, it registers. (Note: This requires the Emergency Revert
Channel to be ARS enabled.)
4. After registration, periodic location updates are sent on the Emergency Revert’s GPS
Revert Channel, f4, until the emergency is cleared.
This configuration in Figure 4-19 “Emergency Alarm and Call and GPS Interaction Diagram” is
useful when a system needs to simultaneously support multiple emergency calls from multiple groups on a single Emergency Revert Channel. The placement of emergency calls on the
Emergency Revert Channel and the location updates on a different channel significantly increases both emergency voice throughput and Location Update throughput while in the emergency state. It should be noted that changing the Emergency’s GPS Transmission Channel to either the Selected
Channel, f1, or the Emergency Revert Channel, f3, removes one control station from the system.
The actual configuration selected depends on actual customer requirements.
November, 2008
198
4.8.7.5.3 Emergency Alarm with Voice to Follow
System Design Considerations
TX=f
RX=f
1
1 f
1
Presence f
1
Location Request
GPS f
3
Presence (Emg.) f
3
Location Request (Emg.)
4
TX=f
RX=f
USB USB f
1 f
3
TX=f
2
RX=f
2
MOTOTRBO
Control Station
(digital mode)
Location
Response f
2
MOTOTRBO SU
(digital mode)
Location
Res pons f
4
MOTOTRBO e (Emg
Control Station
(digital mode)
.)
TX=f
RX=f
4
4
3
3
3
USB 5 USB
1 2
MOTOTRBO
Control Station
(digital mode)
MOTOTRBO SU
(digital mode)
MOTOTRBO
Control Station
(digital mode)
MCDD
Presence Notifier
Location Server
Application Server
Figure 4-20 Emergency Alarm with Voice to Follow and GPS Revert Interaction Diagram
Figure 4-20 “Emergency Alarm with Voice to Follow and GPS Revert Interaction Diagram”
illustrates the channels used when an emergency is initiated and the SU is configured for
Emergency Alarm with Voice to Follow with an Emergency Revert Channel and the Emergency
Revert Channel is configured with a GPS Revert Channel. (Note: The channels are defined in the table in the previous section) The following describes the sequence of events.
1. The SU switches from the Selected Channel, f1, to the Emergency Revert Channel, f3, and then transmits one Emergency Alarm.
2. The SU stays on the Emergency Revert Channel, f3, and initiates an emergency voice call. During the emergency voice call the Emergency Location Update is held in queue.
3. Once the emergency voice call ends, the SU switches to the Emergency Revert’s GPS
Revert Channel, f4, and transmits the Emergency Location Update.
4. After this transmission, the SU switches to the Emergency Revert Channel, f3, and while not being involved in voice calls, it registers. (Note: This requires the Emergency Revert
Channel to be ARS enabled.)
5. After registration, periodic location updates are sent on the Emergency Revert’s GPS
Revert Channel, f4, until the emergency is cleared.
November, 2008
System Design Considerations 199
This configuration in Figure 4-20 “Emergency Alarm with Voice to Follow and GPS Revert
Interaction Diagram” is useful when a system needs to simultaneously support multiple emergency
calls from multiple groups on a single Emergency Revert Channel. The placement of emergency calls on the Emergency Revert Channel and the location updates on a different channel significantly increases both emergency voice throughput and Location Update throughput while in the emergency state. It should be noted that changing the Emergency’s GPS Transmission
Channel to either the Selected Channel, f1, or the Emergency Revert Channel, f3, removes one control station from the system. The actual configuration selected depends on actual customer requirements.
4.8.8 Channel Access Configuration
Channel access methods must be specified in the radio’s codeplug for each channel via the CPS, that is the TX (Transmit) parameters for each defined channel contains an Admit Criteria option that must be set to one of the 3 possible values described below.
• Always,
• Channel Free, or
• Color Code Free.
An Admit Criteria of Always is sometimes referred to as "impolite channel access". An Admit
Criteria of Channel Free is referred to as “polite to all”. Finally, an Admit Criteria of Color Code
Free is referred to as “Polite to own color code”. In polite mode, the radio will not transmit on a channel if there is any activity detected on that channel. In impolite mode, the radio will transmit on a channel regardless of any activity on that channel. When operating in impolite mode a radio user
will cause RF contention if there is another call on the same slot currently in progress. See
“MOTOTRBO Channel Access” on page 16.
Radio users provisioned for polite operation need only press their PTT to determine if they can transmit or not. A Talk Permit Tone or Talk Denial Tone indicates if they have been granted or denied access. Impolite users are allowed to transmit regardless if the channel is busy or idle, although they would still need to wake the repeater.
It is important to note that the LED busy indication on the radios represents the presence of RF activity on the selected channel and is not specific to the digital slot currently being monitored.
Therefore, if the LED indicates no RF activity on the channel, the radio user can be sure their slot is idle. However, if the LED indicates the presence of RF activity on the channel, the radio user will not know if their slot is actually idle or busy. If the radio users transmit when the LED indicates a busy channel, there is a chance their transmission will collide with another transmission. Care should be taken since RF collisions in digital mode most likely results in both transmissions not reaching their intended target. Therefore, it is highly recommend that only well trained and disciplined radio users are configured to have impolite channel access.
4.8.9 Zones and Channel Knob Programming
The MOTOTRBO radio is capable of being programmed with up to 160 channels. Each radio has a 16 position selector knob/switch, in which various channels and call types can be programmed.
In order to maximize the programming capability of the radio, the concept of “zones” is introduced.
Zones can be created on the radio through the channels menu of the CPS. A “zone” can contain up to 16 channels that are mapped to the 16-position top selector knob of the portable radio or the channel number selector on a mobile. Radio users that require more than 16 channels must
November, 2008
200 System Design Considerations organize them into multiple zones in the CPS, so that they can be accessed as “zones” in the radio menu. From the radio menu, the user can navigate to the “zones” icon, select it, and switch to a different zone. When in the different zone, the 16 position selector knob/switch is now programmed with that zone’s channels and call types. It is recommended that the Zone should be given aliases that can be understood by the end user.
4.9 Base Station Identifications (BSI) Setting
Considerations
Base Station Identification (BSI), sometimes referred to as CWID, is used to identify the licensee operating a repeater or base station. Some form of station identification is usually necessary to comply with the requirements of the local radio regulatory authority.
BSI is available on the MOTOTRBO repeater when configured for analog or digital mode. In both modes, BSI is generated using a sinusoidal tone modulated on an analog FM carrier. The station transmits the configured Morse code alphanumeric sequence when one of two configured BSI timers has expired. The Exclusive BSI Timer is named TX Interval in CPS and the Mixed with
Audio Timer is named Mix Mode Timer in CPS. The goal of these two timers is to minimize the impact to the ongoing traffic while still being compliant with regulatory authorities.
TX Interval is used to configure an “Exclusive BSI” which is sent the next time the repeater dekeys. The Mix Mode Timer is used to configure a “Mixed with Audio“ which is mixed with the analog audio on the channel. Mixed with Audio BSI is only utilized when configured for analog operation. Mixing BSI with digital audio is not supported in MOTOTRBO.
When the Exclusive BSI Timer expires, the repeater transmits BSI the next time the repeater dekeys. This allows the BSI to be transmitted without disrupting on going voice, which is ideal.
Furthermore, if the Exclusive BSI Timer expires while the repeater is not active (no subscriber activity) the repeater does not wake up and send BSI. Instead, it waits until the next transmission occurs and then transmits BSI upon de-key. BSI is only required during times of activity. Note that
Exclusive BSI is interruptible in analog mode if the repeater receives a radio transmission. If interrupted, the BSI is attempted again at the next de-key. Also, whenever the repeater is forced to de-key due to a Time Out Timer expiring, it takes the opportunity to transmit an Exclusive BSI.
When the “Mixed with Audio” BSI Timer expires, the repeater performs the BSI mixed with the on going audio on the channel. It is very important to note that there is a two minute hold-off timer when the repeater first keys up. The purpose of this additional hold-off timer is to make sure that the BSI is not mixed with audio immediately after being de-keyed for a long duration. This delay gives the repeater a chance to transmit the exclusive BSI before interrupting the audio.
Both the Exclusive BSI Timer and the Mixed with Audio Timer are reset after completion of a BSI transmission.
It is recommended that the Exclusive BSI Timer (TX Interval) is set at 75% of the regulatory authority’s required BSI period and the Mixed with Audio BSI (Mix Mode Timer) is set at 95% of the regulatory authority’s required BSI period. This way, the repeater begins attempting to send the
BSI exclusively well before the required time. This interrupts the voice with mixed BSI as it gets closer to the required period if it has not found an opportunity to perform BSI exclusively.
BSI can be completely disabled by setting both the Exclusive BSI Timer and the Mixed with Audio
BSI Timer to 255 in the CPS. It is not a valid configuration to disable the Exclusive BSI and only
November, 2008
System Design Considerations 201 have the Mixed with Audio BSI enabled. This results in only Mixed with Audio BSI being sent in scenarios where the repeater is keyed for two minutes.
If the Exclusive BSI Timer is enabled, and the Mixed with Audio BSI is disabled, it is possible that during periods of heavy use, the BSI will not be generated within the configured time period. For analog, it is recommended that the Mixed with Audio BSI is enabled at all times.
Since Mixed with Audio does not operate in digital mode, it is possible that during extended periods of high activity the repeater never has a chance to de-key, and would therefore never have a chance to send BSI. This is more likely on a highly loaded GPS only repeater. This should be combated by lowering the traffic on the channel or by lowering the subscriber inactivity timer (SIT) in the repeater. This de-keys the repeater quicker between transmissions and provide a higher chance of de-key and therefore a higher chance of sending Exclusive BSI in the desired time frame.
Since Exclusive BSI is interruptible in analog mode, a situation may arise where extended periods of high activity may cause the repeater to continually de-key, attempt BSI and then be interrupted by another inbound transmission. The de-keying and re-keying of the repeater causes the hold off timer to be reset and the Mixed with Audio BSI is never triggered unless a particular transmission lasts over two minutes. In this case, it is recommended that the hangtime be increased so that the repeater does not de-key between every transmission. If this period of high activity occurs longer than two minutes, the Mixed with Audio occurs, otherwise the Exclusive BSI occurs during a period of decreased traffic load.
It may not be desirable to enable Mixed with Audio BSI with the use of analog data (i.e. MDC or
VRM data). The mixing of the BSI with the analog signalling will most likely cause the signalling to become corrupted.
4.10 GPS Revert Considerations
GPS revert, when used correctly, can significantly improve the integrated voice and location data performance of a system. In order to maximize location throughput while minimizing missed data
(text, telemetry, etc.) and voice transmissions, there are a number of factors that must be considered.
• Non-location update traffic should not be transmitted on the GPS Revert Channel when attempting to maximize the Location load on the GPS Revert Channel.
• Avoid adding the GPS Revert Channel into the scan list if the location load is high, as scanning radios will often land on this channel and qualify traffic that is not for them. This can slow down scanning.
• While in repeater mode, avoid placing the alternate slot associated with GPS Revert
Channel into the scan list if the location load is high. Scanning radios will often land on this channel to qualify traffic that is not for them. This can slow down scanning.
• It is not recommended to use a portable as a control station, but if a portable is used as a control station then battery saver mode should be disabled since the Location Update messages will not be preceded with preambles.
• Voice, data or control messages that are sent to an SU on the GPS Revert Channel will not be received. The radio is only on the GPS Revert Channel to transmit location updates and it DOES NOT qualify activity on this channel.
November, 2008
202 System Design Considerations
• If group data is to be supported on a system, the inclusion of preambles should be added to minimize the occurrence of the group data message being missed while an SU is on the
GPS Revert Channel.
• Avoid situations where a large number of subscribers are powered on in a relatively short period of time as this causes a flood of registration messages that impacts the voice quality
of service on the Selected Channel during the registration process. See “GPS Revert and
Loading” on page 152. for recommendations on minimizing impact when using Motorola
applications.
• In order to minimize users from inadvertently changing a radio to the GPS Revert Channel, it is recommended that the GPS Revert Channel(s) is placed in a different zone than the primary voice and data channel(s).
4.11 Failure Preparedness
4.11.1 Direct Mode Fallback (Talkaround)
A repeater channel is defined by having different receive and transmit frequencies, and any channel that is programmed with the CPS to have different receive and transmit frequencies will be considered to be a repeater channel and the MOTOTRBO radio will expect a repeater operating on that channel. The radio user will get an access-denied tone if there is no repeater available or if the radio is out of range of the repeater. Channels defined as repeater channels in
CPS can be modified to operate in Talkaround mode via user selection from the menu or a programmable button. When a repeater channel is thus modified to operate in talkaround mode, the transmit frequency is set equal to the receive frequency, and it effectively becomes a direct mode channel. The system now performs similarly to the direct mode topologies we've previously described.
4.11.2 Uninterrupted Power Supplies (Battery Backup)
To determine the UPS capacity you will need, follow these simple steps:
1. List all equipment to be protected by the UPS on a worksheet.
2. Read the nameplate data on each of the devices listed. Write down the voltage and amperage for each device.
3. Multiply the voltage by the amperage of each device to calculate the Volt/Amps (VA).
Some equipment, such as PC power supplies, may be marked with a power consumption measured in Watts. To convert Watts to VA, simply divide Watts by 0.65 (for a power factor of 0.65), or multiply by 1.54. The power factor refers to the relationship between the apparent power (volt-amps) required by the device and the actual power (watts) produced by the device.
4. Total the VA for all devices you want to protect with the UPS and enter it in the "Subtotal" field.
5. Multiply the subtotal found in Step 4 by 0.25 and enter it as the "Growth Factor". This number takes into account room for future growth. This growth factor allows for a 5% rate of growth for each year over a five-year period.
6. Add the "Growth Factor" to the Subtotal" to get the "Required VA". Now you can select the appropriate UPS model by choosing a model that has a VA rating at least as large as the
"Required VA" that you calculated.
November, 2008
System Design Considerations 203
4.12 Configurable Timers
The following is a list of timers that are used to synchronize communication in the radio system.
The values of these timers can be configured through the CPS.
Timer
Name
TX Preamble
Duration
Talkaround
Group Call
Hang Time
Talkaround
Private Call
Hang Time
Description Notes
Preamble is a string of bits added in front of a data message or control message (Text Messaging, Location
Messaging, Registration, Radio Check, Private Call, etc.) before transmission. This preamble prolongs the message in order to reduce the chances of the message being missed by the receiving radio. The Transmit (TX) Preamble
Duration sets the duration of the preamble. This duration needs to be increased as the number of scan members increases on the target radio (refer to the MOTOTRBO system planner for guidance on how to set the duration).
This value can be increased in all the transmitting radios if scanning radios are often missing data messages.
However, a larger preamble occupies the channel longer.
Therefore, increasing the Transmit Preamble duration will increase the success rate of data received while other radios are scanning, but will decrease the amount of data that can be transmitted on the channel. This is a radio-wide feature.
Sets the duration during which a radio talks back to a received call or continues a transmitted call using the previously received or previously transmitted digital Group
ID. This hang time is used during a Group Call in
Talkaround mode to produce smoother conversation.
During this time, other radios can still transmit since the channel is essentially idle. After the hang timer expires, the radio transmits using the Contact Name specified for this channel.
Sets the duration the radio keeps the call setup after the user releases the Push-to-Talk (PTT) button. This is to avoid setting up the call again each time the user presses the PTT to transmit. This hang time is used during a Private
Call in Talkaround mode to produce smoother conversation. During this time, other radios can still transmit since the channel is essentially idle.
The TX Preamble feature is disabled if the duration is set to 0.
This feature is supported in Digital mode only.
This feature is supported in Digital mode only.
–
November, 2008
204 System Design Considerations
Timer
Name
Subscriber
Inactivity
Timer
Group Call
Hang Time
Private Call
Hang Time
Emergency
Call Hang
Time
Description Notes
The Subscriber Inactivity Timer (SIT) controls how long the repeater will continue transmitting with absence of subscriber activity on the uplink. If the repeater is operating on shared-use frequencies, it cannot remain keyed indefinitely for the benefit of broadcasting synchronization signals to subscriber units. The repeater will likely be dekeyed most of the time; thereby requiring subscriber units to first activate the repeater (via the uplink frequency) and acquire synchronization (via the downlink frequency) before completing the call setup request and subsequent first transmission. The net result of these extra procedures is increased access time; therefore, it is desirable to avoid these steps, whenever possible. There is a trade-off to minimizing access time by keeping the repeater keyed for as long as practically possible, while complying with the regulations regarding shared-use channels, which essentially require the repeater to de-key when the channel is not in use. This can be balanced with the use of the
Subscriber Inactivity Timer. If shared use is not a concern, the SIT can be set to the maximum value. If shared use is a concern, the SIT should be set equal to or slightly longer than the configured call hang timers.
Sets the duration the repeater reserves the channel after the end of a group call transmission. During this time, only members of the Group that the channel is reserved for can transmit. This produces smoother conversation.
The value of this feature must be equal to or greater than the
Hang Time (Group,
Private or Emergency
– whichever is the longest).
This feature is disabled if Repeater Mode is set to Analog.
Sets the duration the repeater reserves the channel after the end of a private call transmission. During this time, only the individuals involved in the call that the channel is reserved for can transmit. This produces smoother conversation. The user may want to set a longer hang time than the Group Call Hang Time as an individual tends to take a longer time to reply (talkback) in a Private Call.
Sets the duration the repeater reserves the channel after the end of an emergency call transmission. During this time, only members of the Group that the channel is reserved for can transmit. This produces smoother conversation. The user may want to set the longest hang time as compared to the Private and Group Call Hang Time to reserve the channel long enough to receive an emergency response.
This feature is disabled if Repeater Mode is set to Analog.
The value of this feature must be equal to or less than the
Subscriber Inactivity
Timer value.
This feature is disabled if Repeater Mode is set to Analog.
The value of this feature must be equal to or less than the
Subscriber Inactivity
Timer value.
This feature is disabled if Repeater Mode is set to Analog.
The value of this feature must be equal to or less than the
Subscriber Inactivity
Timer value.
November, 2008
System Design Considerations 205
Timer
Name
Call Hang
Time
TX Interval
Mix Mode
Timer
Pretime
Coast
Duration
Description Notes
Sets the duration the repeater will reserve the channel for after the end of an analog call transmission. During this time, only members of the call that the channel is reserved for can transmit. This produces smoother conversation. As this hang timer is shared among all types of analog calls
(Group, Private, Emergency etc.), the duration should be set following the call type that needs the longest hang time.
The station will generate a Continuous Wave Identification
(CWID) when the repeater has no other repeat audio requests (either analog or digital), analog or all digital hang time has finished and the programmed transmission interval timer period has expired. This feature should be set to a period shorter than the Mix Mode Timer to allow the station the opportunity to send a CWID at the end of a set of user radio exchanges prior to having to send the ID mixed with analog repeat audio.
The station will generate a Continuous Wave Identification
(CWID) mixed with analog audio when the repeater is repeating analog signals or is in analog hang time and the programmed mix mode timer has expired. This feature should be set to a period longer than the TX Interval to allow the station the opportunity to send a CWID by itself at the end of a set of user radio exchanges rather than having to send the ID mixed with analog repeat audio.
This feature is enabled only if Repeater Mode is set to Analog.
–
This feature is disabled by the repeater if the value is set to 255.
This feature is not applicable to digital repeater operation as
CWID will not be generated while digital repeat is in progress.
This feature is supported in Analog mode only.
Sets the duration that the radio waits, after a Push-to-Talk
(PTT) button press, before it starts transmitting the
Motorola Data Communication (MDC) signaling system data packet (e.g. preamble bit sync) and data. When communicating via a repeater system or console, this feature allows the repeater to stabilize before the radio starts transmitting the data. Additionally, this timer gives scanning radios time to land on the channel prior to the reception of MDC data.
If the carrier signal is lost after Motorola Data
Communication (MDC) signaling data is detected, the radio stays muted for the duration of this timer or until the carrier signal is redetected. Once the carrier signal is redetected, this timer is stopped, and the Data Operated Squelch
(DOS) Auto Mute Duration timer begins again. This feature helps to prevent temporary loss of DOS in areas of poor signal strength or signal distortions.
–
November, 2008
206 System Design Considerations
Timer
Name
Auto Mute
Duration
Fixed Retry
Wait Time
Time-Out
Timer (TOT)
Time-Out
Timer Rekey
Delay
Scan Hang
Time
Signaling Hold
Time
Description
Sets the duration that the radio remains muted when the radio is receiving Motorola Data Communication (MDC) signaling data to reduce noise from the data reception. The user has to know the size of the data to select a suitable duration. If the duration is too short then some unwanted noise will still be heard, and if the duration is too long, it might clip some voice audio. This is normally used on radios that support both voice and data on the same channel.
Sets the duration that the radio waits before attempting another polite or impolite transmission to transmit signaling data. Configuring the radios with different wait durations increases the probability of accessing the system and reduces the chances of data lost due to collisions.
The Time-Out Timer (TOT) is the amount of time that the radio can continuously transmit before transmission is automatically terminated. This feature is used to ensure the channel is not monopolized by any one radio. The user may set smaller time-outs for busier channels. This is a channelwide feature.
Sets the amount of time that the radio waits on a channel after the Time-Out Timer expires (which stops the radio transmission) before allowing the user to transmit again.
This is a channel-wide feature.
Sets the duration the radio will remain on a landed channel after the end of a transmission during a scan operation. The hang time prevents the radio from resuming scanning until the conclusion of the response to the initial call. The timer starts after the end of a transmission and resets whenever a valid activity is detected on the channel during the hang time.
Sets the amount of time that the radio waits on an analog scan list channel when a carrier signal of sufficient amplitude is detected on the channel. This pause allows the radio time to decode the analog system signaling data. If the decoded information is incorrect, the radio reverts to scan.
Notes
This feature is supported in Analog mode only.
This feature is supported in Analog mode only.
–
–
It is recommended to increase the hang time value if the call hang timer in the subscriber unit or repeater increases.
This feature must be equal to or greater than the amount of time it takes the radio to transmit the signaling data packet plus the channel's
Signaling Systems
Pretime.
This feature is supported in Analog mode only.
November, 2008
System Design Considerations 207
Timer
Name
Priority
Sample Time
Description Notes
Sets the duration that the radio waits, when in a call, before scanning the priority channels. If the call is taking place on a Priority 1 Channel, no scanning will take place. When scanning priority channels, the radio briefly mutes the current transmission. Increasing this interval improves the audio quality of the current transmission as fewer checks are done, but this also increases the chance of the radio missing out priority channel activity.
A priority member must be present in the scan list.
November, 2008
208
Notes
System Design Considerations
November, 2008
Sales and Service Support Tools
SECTION 5 SALES AND SERVICE SUPPORT TOOLS
209
5.1 Purpose
This module introduces the standard system layout, identifying each component’s role in servicing the system features listed in Module 2. This module is to help the reader understand what devices are needed to support a particular system feature. It will also display the building blocks of the system from a subscriber only system to a mixed mode multi-repeater, data capable system.
5.2 Applications Overview
The three software applications listed below, and their associated drivers are available on the CD kit (GMVN5141).
Name
Customer Programming
Software (CPS)
AirTracer
Tuner
Application Overview
CPS enables a dealer to program the device’s features according to the customer requirements. Navigating around the CPS is now easy and convenient with the addition of a help pane that displays topic-sensitive help instantly without the need to access the online help file.
AirTracer has the ability to capture over-the-air digital radio traffic and save the captured data into a file. AirTracer can also retrieve and save internal error logs from MOTOTRBO radios. The saved files can be analyzed by trained
Motorola personnel to suggest improvements in system configurations or to help isolate problems.
Tuner is an application to tune and test subscriber and repeater products.
Navigating the around the Tuner is now easy and convenient with the addition of a help pane that displays topic-sensitive help instantly without the need to access the online help file.
5.3 Service Equipment
5.3.1 Recommended Test Equipment
The list of equipment contained in the table below includes most of the standard test equipment required for servicing Motorola portable radios, as well as several unique items designed specifically for servicing this family of radios. The Characteristics column is included so that equivalent equipment can be substituted; however, when no information is provided in this column, the specific Motorola model listed is either a unique item or no substitution is recommended.
November, 2008
210 Sales and Service Support Tools
Description Characteristics
Service Monitor Can be used as a substitute for items marked with an asterisk (*)
Example
Aeroflex 2975
(www.aeroflex.com), Motorola
R2670, or equivalent
Application
Frequency/deviation meter and signal generator for wide-range troubleshooting and alignment
AC/DC voltage and current measurements. Audio voltage measurements
Digital RMS
Multimeter*
RF Signal
Generator *
100 µV to 300 V
5 Hz to 1 MHz
10 Meg Ohm
Impedance
100 MHz to 1 GHz
-130 dBm to +10 dBm
FM Modulation 0kHz to 10kHz
Audio Frequency 100
Hz to 10kHz
Oscilloscope * 2 Channel
50 MHz Bandwidth
5 mV/div to 20 V/div
Power Meter and Sensor *
5% Accuracy
100 MHz to 500 MHz
50 Watts
Fluke 179 or equivalent
(www.fluke.com)
Agilent N5181A
(www.agilent.com),
Ramsey RSG1000B
(www.ramseyelectronics.com), or equivalent
Leader LS8050
(www.leaderusa.com),
Tektronix TDS1001b
(www.tektronix.com), or equivalent
Bird 43 Thruline Watt Meter
(www.bird-electronic.com) or equivalent
Receiver measurements
Waveform measurements
Transmitter power output measurements
RF Millivolt
Meter
100 mV to 3 V RF
10kHz to 1 GHz
Power Supply 0 V to 32 V
0 A to 20 A
Boonton 92EA
(www.boonton.com) or equivalent
B&K Precision 1790
(www.bkprecision.com) or equivalent
RF level measurements
Voltage supply
November, 2008
Sales and Service Support Tools 211
5.4 Documentation and Trainings
5.4.1 MOTOTRBO Documentation
The following items listed are documentation provided by Motorola to support the entire range of products available in the MOTOTRBO system.
Motorola Part No.
GMLN4575D
6866574D01
6866574D05
6866574D02
6866574D06
6866574D04
6866574D35
6866574D29
6866575D33
6866575D40
6866575D01
6866575D05
6866575D02
6866575D06
6866575D04
6866575D26
6866576D03
6866576D16
6866576D02
Name
MOTOTRBO Publications CD
DP 340x Quick Reference Guide (Multilingual)
DP 340x User Guide
DP 360x Quick Reference Guide (Multilingual).
DP 360x User Guide
DP 3000 Series Accessory List Leaflet
DP 3000 Series Detailed Service Manual
DP 3000 Series Basic Service Manual
DM 3000 Series Basic Service Manual
DM 3000 Series Detailed Service Manual
DM 340x Quick Reference Guide (Multilingual)
DM 340x User Guide
DM 360x Quick Reference Guide (Multilingual)
DM 360x User Guide
DM 3000 Series Accessory List Leaflet
DM 3000 Series Installation Manual
DR 3000 Basic Service Manual
DR 3000 Detailed Service Manual
DR 3000 Installation Guide
November, 2008
212 Sales and Service Support Tools
5.4.2 MOTOTRBO Trainings
Motorola offers both Sales and Systems (technical) training courses on the MOTOTRBO system.
November, 2008
advertisement
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project