Radio Management
In the past, setting up radios involved connecting each radio to a PC, reading the radio, making the required changes and writing this back to the radio again. If only a few radios needed to be set up and the configuration was simple, this was not a problem. But, if the radios were in different places and/or there were many of them, implementing the change was tedious work, taking many days or weeks or sometimes months to complete.
Additionally, if some radios are at remote locations, the technician would need to travel there; locate the equipment; make the changes and travel back. - a waste of their time, apart from the cost of travel.
MOTOTRBO Radio Management (RM) solves this by centralizing management of all radio configurations in a system or multiple systems. Historically, radio system configuration parameters would have been stored as individual codelug files - one codeplug per Motorola device. For small systems with simple configurations, this wasn't too much of a hassle but for larger systems, this becomes troublesome and can, in many cases, lead to misconfiguration if important parameters are missed or transposed.
RM also enables the over-the-air configuration update of radios by means of over-the-air programming (OTAP).[1][2]
MOTOTRBO Radio Management (RM) offers the following services:
- Writes and reads radio configurations over-the-air (OTAP)
- Manages up to 50.000 radio configurations
- Supports group and individual archive management
- Application and radio mutual authentication
- Synchronized configuration switchover
- Radio user receives one time option to accept or delay
- Scheduling of over-the-air operations
- Unmanned batch processing of numerous over-the-air operations
- Remote client capability
- Multi-customer and system capable
- Optimized performance using Presence Services
- Compressed and differential configuration transfer
- Designed to allow voice traffic priority while transferring
- Utilizes existing over-the-air encryption
- Session logging
- Historical reporting
The above features are available in all digital architectures including direct mode (simplex).
The following features and services are specifically not supported by OTAP:
- Radio software upgrades*
- Language packet updates*
- Radio tuning parameter updates
- Device recovery
- Update or download voice announcement files*
- Radios prior to software version R02.10.00
- Over-the-air repeater programming
- Programming while in Analog Mode
Radio software upgrades; language packet updates and updating voice announcement files are all possible via WiFi - if available.
Basic Deployments
There are six basic deployments of Radio Management (RM) for OTAP. These are used as the building blocks for more complicated configurations and include:
- Local Single Channel Configuration
- Local Single Channel Configuration with Presence
- Remote Client Configuration
- Remote Client Configuration with Multiple RM Servers
- Remote Device Programmer Configuration
- Multi-Channel Configuration
Local Single Channel Configuration
Radio Management utilizes the existing MOTOTRBO IP data service to communicate with the field radios over-the-air. Connectivity with the system can be achieved over-the-air through Control Stations or over the IP network utilizing the MOTOTRBO Network Interface Service (MNIS). No other over-the air data application is supported on the same PC as the RM. This control station setup requires a radio to be configured as a control station, connected to the RM PC via a USB cable and utilized as the data gateway into the radio system. The standard radio USB driver is also required.
The MNIS setup requires the MNIS software to be installed on the RM PC and the Network Application Interface be enabled in the repeaters. MNIS deployments are not available in Direct Mode since the MNIS interfaces directly with the repeaters, and there are no repeaters used in Direct Mode. - except when ERDM is used.
Local Single Channel Configuration with Presence
The RM can utilize ARS and the presence service of the DDMS software to optimize over-the-air operations. When utilized, radios are only contacted if they are present. ARS must be configured in the radios.
Without presence and DDMS, the RM attempts to contact each radio one by one, regardless if they are present on the system or not. For optimal performance, it is recommended that the presence service be utilized.
If utilized, the DDMS is installed on the same computer as the control stations or the MNIS.
RM consists of four major components:
- RM Client: Main User Interface
- RM Server: Storage of Configurations
- RM Job Processor: Compiling and decompiling OTAP data
- RM Device Programmer: Communication to Radio System
In local deployments, all four components can be installed at the same time on the same computer. This is most useful when the system administrator is within RF coverage of the radio system. Below is a diagram showing the individual components. This is the same when utilizing MNIS.
Remote Client Configuration
If the system administrator is not within RF coverage of the system, it is possible for the RM Client to be installed on a different PC and remotely access the RM Server and Device Programmer over an IP network.
Direct network connectivity is required between the RM Client and the RM Server, therefore a VPN must be used or they must reside on a private network. The RM Server, RM Device Programmer, and control stations are located on the same PC.
When utilizing the MNIS, the RM Client can also be installed on a different PC from the RM Server. This allows the RM Server and RM Device Programmer to remain centrally located while the RM Client is located at another location on the IP network. The RM Device Programmer must be installed on the same PC as the MNIS.
Remote Client Configuration with Multiple RM Servers
The RM Client can connect to any RM Server, but only one at a time. This allows the system administrator access to different customers with non-overlapping RF coverage from one location. Although the RM Server, Device Programmer, and control stations must be within RF coverage, the RM Client does not. Each RM Server manages its own set of radios. Direct network connectivity is required between the RM Client and the RM Server; hence a VPN must be used or they must reside on a private network. However, it is not necessary for the network connection between the RM Client and the RM Server to be up all the time. The system administrator can set up a job with one RM Server, and then disconnect. The RM Server continues to execute.
Remote Device Programmer Configuration
RM Server can support up to 128 RM Device Programmers. This allows the system administrator to have all radios in one RM Server and have access to different sites with non-overlapping RF coverage. Device Programmer and control stations must be within RF coverage of their corresponding systems, which is unnecessary for the RM Server.
A stable and direct network connectivity is required between the RM Server and RM Device Programmers. Therefore a VPN must be used, or they must reside on a private network. If a stable, direct network connectivity is not possible, a Remote Client Configuration with multiple RM Servers installed on the same PC as the Device Programmers, may be required.
If utilizing presence, the Device Programmer where the target radio has registered, services jobs for that radio. A Device Programmer can also be configured to only service a specified set of radios. This is accomplished by setting the radios to a group within the RM Server, and then configuring the Device Programmer to service that group only.
Multi-Channel Configuration
Multiple conventional channels are supported per RM Device Programmer in both local and remote configurations. This requires a control station per channel, up to 16 are allowed. Because radios can move from channel to channel, this configuration requires the Multi-Channel Device Driver (MCDD) and DDMS to be installed on the same PC. The MCDD tracks the location of the radios as they move from channel to channel. As they register with the DDMS, the MCDD updates the routing accordingly.
It is not recommended to utilize multiple control stations without the MCDD and DDMS. Without both, there is no method for RM messages to be properly routed on the appropriate channel. Specific routing can be added in the PC, but this means radios can only be contacted on a specific channel. Another option is to configure the PC to broadcast on all channels, but this is an extreme waste of system resources.
A multiple channel configuration can be deployed with remote RM Device Programmers, remote RM Servers, or a remote RM client. The RM works the same regardless if the control stations are communicating in direct mode, single site repeater mode, dynamic mixed mode, IP Site Connect mode, Capacity Plus Single Site mode, or Capacity Plus Multi Site mode.
When utilizing MNIS with DDMS, there is no need for MCDD. DDMS handles the mobility in single site and IPSC systems. DDMS requires ARS to be enabled in the fielded radios. MNIS can connect to eight conventional systems.
Process Flow for Over-the-Air Programming
There are five high-level steps for Over-the-Air Programming (OTAP), as follows:
- Initial programming of the essential communication parameters into the radio via wired CPS
- Populating the RM Server with the current radio configurations
- Modifying the radio configuration within the RM Server
- Delivering the modified radio configurations to the radios
- Applying (or switching over) the delivered radio configurations
Essential Communication Parameters required for Initial Programming
Prior to the first time a radio is programmed over-the-air, it must be provisioned with CPS through a wired connection. All the essential communication parameters required for the radio and the RM to communicate with each other on the system must be programmed.
The following are they essential communication parameters:
- Radio software upgrades
- System and channel parameters
- Data parameters
- Radio ID
- OTAP authentication key
Radio Software Upgrades
For radios with fiormware older than R02.10.00, any radio software upgrades required for over-the-air operation must be updated through Radio Management in a wired operation (via a USB cable) as software upgrades are not supported over-the-air. This does not apply to repeaters which can be updated via IP. Radios which support WiFi can be updated via WiFi.
System and Channel Parameters
All system and channel parameters required for the radio to communicate with the system must be configured prior to the first operation over-the-air. This includes the standard communication parameters such as frequencies, color codes, channels, talkgroups, voice privacy keys, and so on. If the radio cannot communicate on the system properly, the RM will not be able to contact it.
Data Parameters
RM utilizes the MOTOTRBO data service to communicate with the radios. This means that all communication parameters required for data capability must be provisioned prior to the first operation over-the-air. This includes the ARS parameters.
Radio ID
In MOTOTRBO systems, the data service requires every radio to have a unique radio ID.
If utilizing a centralized RM Server to communicate with multiple systems using Remote Device Programmers, every radio across those systems must have unique radio IDs. If this is not achievable, then OTAP sessions to systems with duplicate IDs have to be executed sequentially – only one at a time, or a separate RM Server must be utilized for each system. Ultimately, end-user fleets should be reconfigured to unique IDs so that multiple OTAP sessions to multiple customer fleets can be processed simultaneously.
Over-the-Air Programming Authentication Key
The only new OTAP parameter required to be programmed in the radio is the OTAP authentication key and key ID.
It must be present in both the radio and in the RM prior to the first over-the-air operation. The OTAP authentication key can be changed over-the-air if the current key in the radio matches the previous key entered in RM.
Delivering the Modified Radio Configurations to the Radios
Once the updates have been made to the radio configurations within the RM Server, their status gets updated to “Codeplug Modified”. This means that the configuration needs to be delivered to the radio over-the-air.
The RM allows scheduling of multiple radio configurations to be delivered over-the-air unattended. The RM starts the delivery at the scheduled time and continues until all selected radios are either complete, errored, or canceled. It is recommended that over-the-air operations are scheduled during low traffic in order to minimize the impact on the system performance. The delivery mechanism over-the-air allows for voice to coexist with the RM data, although system performance may be degraded slightly. The mechanism can also handle radios that enter and leave RF coverage. It utilizes presence to optimize the delivery.
The time it takes to deliver a configuration to a set of radios is dependent on the number of radios and the amount of changes to the configuration currently in the radio.
A pacing option is available to add additional delay to the delivery process. This is useful when delivery time is not important and it is desirable to minimize impact on the system performance. The pacing option is set to zero unless manually changed in the RM Device Programmer.
Switching Over the Delivered Radio Configurations
A delivery has an option to simply deliver the new configuration without applying it, or to apply it immediately after delivery. Applying the configuration is known as a “switchover”.
When changing critical communication parameters, it is recommended that the new configuration is delivered to all the radios first, and then a separate switchover is delivered to the same set of radios. This minimizes the downtime by applying all configurations at the same time. If making minor changes to the configuration, for example address book entries or button configurations, it is acceptable for each radio to apply the changes immediately as they are delivered.
Although the first radio may end up receiving the address book before the last radio, there would be little impact on the system operation. In contrast, if updating a critical communication parameter like transmit or receive frequency, the first radio is out of communication with the last radio until the last radio receives its programming.
Delay Option and Switchover Timer
A configuration switchover has the option for a max delay timer, also known as the switchover timer. The switchover timer is the maximum duration the radio waits after receiving the switchover message before performing the switchover.
Because radio users have the option to accept or delay, it is not recommended to have a large switchover timer when changing critical communication parameters. Otherwise the first radio applies its changes well before the last and results in possible communication disruption.
If the switchover timer is set to zero, there is no prompt at the radio, and the switchover occurs immediately upon receiving the switchover message. If the value is greater than zero, the radio user receives a prompt to accept or delay the switchover.
If accept is selected, the radio immediately resets and applies the changes. If there is no selection or a delay is selected, the radio continues to operate on the old configuration until the switchover timer expires, at which time the radio resets and applies the changes.
If in an emergency or in a voice call when the switchover timer expires, the radio delays the switchover until the emergency is cleared or the voice call is over. If at any time while the switchover timer is running and the radio user cycles power, the configuration is applied on power up.
Presence Registration Suppression
If switching over many radios independent of the delivery and utilizing a zero value switchover timer, the radios may be reset within a short duration of each other. This may result in radios sending their presence registration, also known as their automatic registration service (ARS) message, within a short duration of each other, which may result in channel blocking. There is an option available in the RM to enable or disable the radio from sending a presence registration immediately after a switchover.
If making changes to the radio configuration that does not affect the channel assignments, like address book entries or button layout, it is not necessary to re-register with the DDMS. Therefore presence registration can be suppressed after a switchover. If making changes to the radio configuration that affects the channel assignments, like adding, changing or removing channels, it is necessary to re-register with the DDMS. Therefore presence registration should not be suppressed after a switchover.
Access to the Last Modified Date and Time via the Radio Menu
The radio user can access the radio menu to see the date and time the configuration was modified. This represents the date and time the codeplug package was compiled by the device programmer just prior to delivery.
WiFi
MOTOTRBO Radio Management supports all device configuration operations via WiFi which includes.
- Configuration of Device Settings
- Update of Device Firmware
- Activation of Premium Features
- Updates of Device Resources (i.e. Language Packs and Voice Packs)
Radio Management Device Programmer must be present on the same local area network (LAN) as the MOTOTRBO device. This is required because Device Programmer identifies MOTOTRBO devices using the DNS-SD protocol. The deployment of a virtual local area network (VLAN) does provide additional deployment options when physically deploying Device Programmer on the same LAN is not feasible.
Wi-Fi On-Off Control
It is now also possible to enable or disable Wi-Fi via an over the air radio command. For example, this feature could be used for the following:
- The Wi-Fi could be turned on only when the radio is at a depot (or some central location) for a firmware and/or configuration update.
- The Wi-Fi could be turned on only when the radio is indoors or within Wi-Fi coverage allowing communications over WAVE.
Wi-Fi consumes a small amount of current, so turning it off when not needed will contribute positively to battery discharge time.
Wi-Fi On-Off Control is available in R2.10.0.
System Components
Radio Management Server
The RM Server is the central database that stores and manages all radio data, templates, and configurations. Only one RM Server is supported in an RM system. All clients in an RM system interface with the RM Server to manage the entire fleet of radios.
- The management of server settings and database operations are performed with an integrated application called the RM Server Utility. The RM Server Utility supports the following operations:
- Status of all RM services
- Database settings for backup and restore
- User and Machine Authorization
- Network settings
Job Processor
The RM Job Processor (JP) is a Windows-based service that validates the data in the RM Server and transforms the radio data into a format that can be written to a radio.
Motorola Solutions recommends deploying the RM Job Processor on the same computer as the RM Server. When using multiple RM Job Processors, it is recommended to colocate the JPs with the RM Server and connect them to the same physical subnet on the network.
Deploying too many RM Job Processors is not recommended because it may impact the performance of the Radio Management software.
Deploying multiple RM Job Processors across a Wide Area Network (WAN) is also not recommended due to the potential for network errors when transferring large amounts of data between the RM Job Processor and the RM Server.
Device Programmer
The RM Device Programmer (DP) is a Windows-based service that performs scheduled programming jobs stored in the RM Server.
The RM Device Programmer is configured to process either USB and/or Wireless (LAN) or Over The Air jobs using the RM Device Monitor. Wired jobs require an RM Device Programmer configured for USB and OTA jobs require an RM Device Programmers configured for Over The Air. The RM Device Monitor provides the user-interface to configure the RM Device Programmer and continuously monitors for the presence of radios that have scheduled jobs stored in the RM Server. The RM Device Monitor does not need to be open to process available jobs.
Each RM Device Programmer in the RM system can program up to 16 radios simultaneously. If using a USB hub, ensure that it is a powered USB hub.
RM Device Programmers can also be configured to program radios using Wi-Fi.
Radio Management Client
The RM Client application is the primary user interface in an RM system. It allows the user to view and manage all the radios in the fleet. Multiple RM Clients are supported in an RM System. Prior to R2.10.0, the RM Client supported two modes of operation:
Template Mode
In Template Mode, the RM Client is integrated into the Customer Programming Software (CPS) application and used only to manage and distribute templates. The programming of templates is performed using CPS.
Configuration Mode
In Configuration Mode, the RM Client is used to program, edit, and distribute configurations. There is no CPS application.
In a single RM system, customers can install both CPS with RM and RM Configuration Client. Installing both applications allows the customer to convert templates to configurations. However, the same radio cannot be managed in both modes.
As of R2.10.0, RM only supports Configuration Mode.
Device Discovery and Mobility Service (DDMS)
DDMS is only used on Simplex; Single Site; IP Site Connect and Capacity Plus systems.
Motorola Network Interface Service (MNIS)
RNDIS Driver
The RNDIS Driver is used to set the radio up as a network connection.
See RNDIS.
It would only be used on Simplex; Single Site; IP Site Connect and Capacity Plus systems.
Multi-Channel Device Driver (MCDD)
MCDD is used when there is more than one Control Station connected to the PC. It is used to set the radios up as network connections and to manage the IP routing between radio and computer. It would only be used on Simplex; Single Site; IP Site Connect and Capacity Plus systems.
Minimum Hardware Specifications
| Component | Requirements |
|---|---|
| Operating System | Windows 10 (32 & 64-bit)
Windows 8 (32 & 64-bit) Windows 8 Pro (32 & 64-bit) Windows 7 Home Premium Edition (32 & 64-bit) Windows 7 Professional Edition (32 & 64-bit) Windows Vista Home Premium Edition (32 & 64-bit) Windows Vista Business Edition (32 & 64-bit) Windows XP Home/Professional Edition with SP3 & Windows Installer 3.1 (32 & 64-bit) Windows Server 2008 R2 (32 & 64-bit) (for Server Installations) |
| Memory | RM Client / RM Server / RM Device Programmer
Install: 1 GB and above required by host Operation System. RM Server / RM Device Programmer Install: 1 GB and above required by host Operation System. RM Client Only Install: RAM required by host Operation System. |
| Hard Disk | RM Client / RM Server / RM Device Programmer
Install: 5 GB (Program Files & Database) RM Server / RM Device Programmer Install: 5 GB (Program Files & Database) RM Client Only Install: 400 MB (Program Files & Archive Files*) * More space would be required if saving archive files of your radios and device update packages. Each archive file or device update package varies in size depending on the features of the radio. |
| Other | USB ports (1 or more depending on system
configuration). Network Connection. DVD Drive. |
| Software | Running multiple instances of the RM application
on one computer is not recommended. When installing the RM Server on Windows XP, the RM Client, Job Processor and Device Programmer must be installed on the same machine. For distributed RM systems, the RM Server requires Windows Server 2008, Windows 7- 10. |
Configuration Examples
RM with a Separate Client and OTAP via a Control Station
The above setup consists of the following:
- Radio Management Client PC running Microsoft Windows; the Radio Management Client application and connected to an IP network, either via WiFi or via an Ethernet cable. A laptop PC is shown here but the client can run on a Desktop or Notebook.
- Radio Management Server running Microsoft Windows; the Radio Management Server; Job Processor; Device programmer and DDMS. The Server is connected to the same IP network as the Client PC. A rack-mount server is shown here but a standard PC conforming to the above-mentioned hardware requirements will also do.
- A Control Station. Not shown is the DC power supply for this radio. Since this radio may be transmitting regularly, the power supply should be able to withstand the current and duty cycle requirements. Since the Control Station is connected to the Server via a USB cable, the Server will need to have the RNDIS driver. The USB cable is the programming cable for that model. In principle any MOTOTRBO radio can operate as a Control Station.
The Radios and Antenna are merely shown for completeness.
- The above setup has the following shortfalls:
- Only one radio can be programmed (via OTAP) at a time.
- The Control Station (and consequently the Server) must be within RF range of the system the Radios operate on.
- Capacity Max is not supported.
The above setup would be best suited for small systems with a relatively small number of radios.
See Also
MOTOTRBO Radio Management Guide for Technical Staff