Motorola ARS, or Automatic Registration Service, is a Motorola DMR data signalling mechanism used by radios to tell a configured application server that the radio is present on the network. IPSC3 uses ARS as one source of roaming and presence information for Motorola radios.
IPSC3 can receive, acknowledge, store, and use Motorola ARS registration traffic. The implementation is based on field captures from Motorola radios and repeaters on the IPSC3 network. It should be treated as practical implementation documentation rather than a complete vendor protocol specification.
4005.4005 as ARS-related.IPSC3 also handles Motorola ARS when it arrives through an MMDVM hotspot. The MMDVM path reassembles the DMR private-data blocks back into the same Motorola IP/UDP payloads used on the IPSC repeater path, then applies the same ARS parser and roaming update logic.
When a Motorola ARS registration is received from an MMDVM hotspot, IPSC3
now sends the ARS acknowledgement back through the same connected MMDVM peer.
The acknowledgement is generated as Motorola ARS UDP payload
00 01 3F, wrapped back into MMDVM DMRD private
data, and transmitted to the hotspot on the received timeslot.
On an initial ARS registration from an MMDVM hotspot, IPSC3 can also queue:
Periodic ARS keepalive and LRRP polling also support MMDVM-hotspot radios. IPSC3 resolves the target from the live connected hotspot runtime before sending a scheduled MMDVM probe. If the hotspot is not connected, the probe is skipped instead of creating a failed transmit request.
Scheduled MMDVM ARS-query and LRRP probes are held while the target hotspot timeslot has active or very recent traffic. ARS ACKs are not delayed, because they are direct responses to a radio registration packet.
The ARS registration payload decoded by IPSC3 has this broad structure:
| Field | Meaning |
|---|---|
| Length | Two-byte big-endian payload length following the length field. |
| Header | Low nibble identifies the PDU type. IPSC3 currently accepts registration PDU type 0x00. |
| Header extension | If present, contains an event ID. IPSC3 treats event ID 0x01 as initial registration. |
| Device ID | Optional length-prefixed ASCII device ID. In current captures this commonly contains the radio ID. |
| User ID | Optional length-prefixed ASCII user ID. |
One observed initial registration payload was:
00 0C F0 20 07 35 30 35 32 35 36 32 00 00
IPSC3 decodes this as an initial registration with device ID
5052562 and no user ID.
IPSC3 recognises these small ARS payloads:
| Payload | Meaning in IPSC3 |
|---|---|
00 01 3F | ARS keepalive/query response. |
00 01 31 | ARS deregistration or radio shutdown indication. |
IPSC3 can also send an ARS query payload:
00 01 14
This is used as a lightweight keepalive probe for radios that previously registered with ARS.
ARS keepalive probing is handled by the IPSC3 background signalling worker, not by the live voice path. The configured ARS radio-check interval controls when probing starts for an ARS-present radio that has not recently answered or keyed up.
On a Motorola IPSC repeater route the direct and regional repeater probes are Motorola radio-check style short commands. On an MMDVM hotspot route IPSC3 uses an ARS-query private-data probe. Any ARS keepalive response, ARS registration, or normal keyup from that radio refreshes the radio's live roaming state and clears the in-progress probe state.
The regional search depends on position data for the last known anchor site. If IPSC3 cannot determine a valid repeater or hotspot position, it cannot fan the search out geographically and the ARS entry expires after the same regional retry timing.
When ARS is received, IPSC3 stores the radio as Motorola ARS-present in the roaming/last-seen model. Stored information includes:
ARS radios are treated differently from ordinary last-heard-only radios. A radio that has sent ARS can be kept in the roaming table based on ARS presence rather than only on normal voice/data keyups.
In the ARS packets currently decoded by IPSC3, we do not receive the radio's selected channel name, zone, CPS channel number, or current talkgroup knob position. IPSC3 can know that a radio registered via a particular repeater or peer on a particular timeslot to the configured ARS service ID, but it cannot infer which voice channel the user has selected unless the radio keys up or sends another packet that carries that context.
ARS is separate from other Motorola data services:
| Service | Observed Purpose | IPSC3 Status |
|---|---|---|
| ARS | Registration and presence. | Implemented for roaming presence. |
| TMS | Text messaging. | Implemented for IPSC3 service SMS paths. |
| BMS | Battery/status style data. | Field testing and partial decode. |
| LRRP | Location request/response. | Implemented for ARS-present radios, field testing ongoing. |
ARS provides the live routing context needed to poll a Motorola radio for LRRP GPS position. Once a radio is ARS-present, IPSC3 can send LRRP requests to the repeater and timeslot where that radio is registered. LRRP processing is documented separately in Motorola LRRP GPS.
Scheduled LRRP GPS polls and Motorola radio-check probes are held while the target repeater or hotspot timeslot has active or very recent traffic. This prevents background data probes from cutting across a live voice over.