DMR IP Data & Messaging

IP Data Basics

RATS welcomes experimental IP data applications on our repeater with prior authorization.

►  IP data services are best suited for UDP-based applications with very small packet sizes and infrequent transmissions.

►  The DMR protocol automatically prioritizes voice traffic over data.  Light to moderate data use will generally not impede voice traffic.

►  All data activity should be on timeslot 1, except timeslot 2 may be authorized during special events.

►  You are required to use a software or hardware firewall to prevent unwanted (non-DMR) packets from going out over the DMR network interface.

In order to use any DMR data features, every data radio on the repeater/frequency must have a unique ID.  The IP address is calculated from the CAI Network and DMR ID.  Non-unique IDs will create IP address conflicts.

🛑  All users must obtain the permission of the repeater owner before using DMR data applications on any DMRVA network repeater.  Our Technical Committee handles data authorizations for the RATS repeater.  DMR data applications may not be welcome on other repeaters.

Protocol Data Unit (PDU) and Transmission Preamble

The codeplug Protocol Data Unit (PDU) setting determines the maximum packet size that will be accepted across the network connection.

►  RATS expects a PDU of 500 for all data applications on our repeater.

►  A higher PDU may be appropriate for simplex operations.  All participating nodes should be configured for the same PDU, so sticking to 500 is recommended.

►  Packets exceeding the PDU length will be dropped by the radio.

According to Motorola's documentation, the TX Preamble Duration "prolongs the message in order to reduce the chances of the message being missed by the receiving radio."

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 [...]. 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.

►  Valid ranges are 0 to 8640 ms, in increments of 60 ms.  RATS expects a TX Preamble Duration not to exceed 120 ms for data radios operating through our repeater.

Talkgroup, Timeslot, Data Call Confirmation

It is not necessary to set a channel TX Contact when configuring a data radio.  Any talkgroup set on the channel has no bearing on transmission of outbound packets.  Timeslot, color code, and admit criteria of course must be set on whichever channel the radio is using for data service.

🛑   Data Call Confirmation must be disabled.

Firewall Required

All users engaging in data activities on the RATS repeater are required to utilize a properly configured software or hardware firewall in order to prevent unwanted non-DMR packets from flowing out over the DMR interface.  This is particularly problematic where a workstation has a working Internet connection that is actively being used, since many Internet domains, including a bunch of popular ISPs and CDNs, have IPs which overlap with the DMR subnets, which results in numerous requests for Internet resources being routed to the DMR network.  Changing the CAI is not enough.  The firewall must:

►  Accept inbound messages and other traffic on standard ports (UDP 4007 and 5016) and forward to PC

►  Accept outbound packets only on UDP ports 4007, 5016, and any other ports specific to your application, when headed for the DMR subnets

►  Block all other traffic headed to the DMR subnets (12.0.0.0/8, 13.0.0.0/8, 14.0.0.0/8, and 225.0.0.0/8 for standard CAI configurations)

When making your request for authorization to use data applications on our repeater, you will be asked about your firewall.

⚠️  Failure to adequately block unwanted outbound traffic can result in significant RF network congestion.  Offending radios may be permanently blocked from the system.

We have found that Mikrotik RouterOS devices make excellent DMR data firewalls.  Any Mikrotik router running RouterOS 7 or a recent release of RouterOS 6 can be configured to selectively route only certain ports over the DMR interface, while sending everything else over existing LAN or WAN routes.  Motorola radios connected via USB cable to a Mikrotik router's USB port will be detected as LTE interfaces and automatically configured with a CAI Network IP using DHCP.  We plan to publish a detailed guide on how to set this up, sometime in the near future.

Text Messaging

General text messaging usage guidelines can be found on our System Features page.  Key points:

►  Except for messaging between Richmond and Petersburg, text messages do not leave the repeater.  You cannot message someone on another repeater or network.

►  Text messages do not cross timeslots -- you cannot message someone on timeslot 1 from timeslot 2, or vice-versa.

►  For Motorola TMS and Hytera messaging, both the sender and recipient must have unique radio IDs.  Messaging may perform unpredictably if more than one radio is using the same ID.

🛑 Text messages are not permitted to any talkgroup that appears on the DMRVA talkgroup matrix.  If you need a messaging talkgroup assigned for a special application, please contact techcomm@rats.net and we'll get you in touch with the right people.

Text Messaging Protocols

DMR allows the exchange of short text messages between any two or more radios with unique radio IDs.  Text messages can be directed to an individual radio or to an entire talkgroup, provided the sending and receiving radios are all speaking a commonly understood language.  There are at least three common text messaging protocols:

• DMR Standard SMS - Defined in the ETSI DMR standard.  Supported by newer Motorola and many non-Motorola transceivers.  No delivery acknowledgment or retry.

• Motorola Text Message Service - Motorola proprietary format.  Supported by all Motorola and many non-Motorola radios.  Shorter message length, with acknowledgement.

• Hytera Messaging - Hytera proprietary format.  Supported by Hytera and a small number of non-Motorola radios.

We don't have any documentation (yet) on working with Hytera messaging.  The information on this page is focused on ETSI DMR Standard and Motorola TMS messaging.

The easiest way to get started with messaging is to build a simple plain-text UDP listener and sender that operates on port 5016.

Transmitting Messages

Messages can be addressed to a radio or to a talkgroup, as long as the corresponding IP address is known.

►  ETSI DMR Standard messages can be sent by transmitting a plain-text, UTF16-encoded string to a destination radio or talkgroup IP address on UDP port 5016.

►  Motorola TMS messages are UTF16-encoded strings with special headers that include a message sequence ID, message type, length, and other details.  TMS messages are transmitted and received on UDP port 4007, and an acknowledgment packet should be sent for all received messages.

Receiving Messages

Most radios will receive text messages sent to the channel TX Contact (if any) or to any talkgroup in the active channel's RX Group List.

To avoid missing messages and other data packets, Scan Lists should be avoided if they take the radio off the frequency or timeslot (use a RX Group List instead).

When a message is received at your radio:

• If the message was sent from a radio to your radio ID or a talkgroup in your RX Group List:

  • It will be displayed on your radio if the codeplug Forward to PC option is disabled

  • It will be forwarded to your PC on UDP port 4007 (TMS) or 5016 (SMS) if the codeplug Forward to PC option is enabled

  • You can determine which radio ID sent the message and whether it was a direct or group message based on the originating IP address and inbound subnet, but you cannot determine which specific talkgroup the message was sent to

• If the message was sent from a PC to your radio ID:

  • It will be displayed on your radio if the codeplug Forward to PC option is disabled and the message was addressed to your CAI Network IP (default 12.x.x.x)

  • It will be forwarded to your PC if Forward to PC is enabled and the message was sent to your CAI Network IP (default 12.x.x.x)

  • It will be forwarded to your PC regardless of the Forward to PC setting in the codeplug if the message was sent to your CAI+1 Network IP (default 13.x.x.x)

  • You can determine which radio ID sent the message based on the originating IP address

• If the message was sent from a PC to a talkgroup in your RX Group List:

  • It will be displayed on your radio if the codeplug Forward to PC option is disabled

  • It will be forwarded to your PC if Forward to PC is enabled in the codeplug

  • You can determine which radio ID sent the message based on the originating IP address, but you cannot determine which specific talkgroup it was sent to.

Station Identification

All radios using DMR data services must ID at regular intervals per FCC Part 97 regulations.  We promote the use of an Identification, Data, and Control (IDC) talkgroup and standardized ID beacon format, and encourage application developers to adapt and incorporate this format for simple station identification that can be widely received and understood by both PC applications and regular radios.