Indoor location tracking on simplex with DCDM

An interesting question came in the other day from one of the Resellers I work with. 

They have a customer who would like to track the location of MOTOTRBO portable two-way radios in a plant. The users are indoors so GNSS will not work in this case. The plant is comparatively small so simplex works well for them.

To implement indoor location tracking on a conventional system using a Control Station, they would have to configure the radios to scan for deployed BTLE Beacons and transmit this proximity data using LRRP. The Control Station, connected to the PC via USB, must be configured to receive these LRRP updates over the air and route them to the mapping application.

The MOTOTRBO indoor location feature uses Bluetooth Low Energy (BLE) iBeacons and the same LRRP system topology used for outdoor GPS tracking.

In terms of configuration, you would need to enable Bluetooth on all portable radios and the Indoor Location setting would need to be set to on. 

You would also also need to add the Beacon UUIDs (up to 20) that match the deployed iBeacons (usually they all have the same UUID). When setting up the radio remember to configure the Scan Interval On Time / Off Time duty cycle to properly align with the BLE Advertisement Interval of the beacons to ensure reliable detection.

Lastly, point the radios to the location application server by setting their ARS Radio ID to the unique Radio ID assigned to the Control Station.

MOTOTRBO radios do not send unsolicited location updates. The third-party location application must send an explicit LRRP request (such as a periodic or event-driven request) to the radios via the Control Station.

When a radio detects an iBeacon, it encapsulates the beacon's data (UUID, Major, Minor, TX Power, RSSI, and Timestamp) inside an LRRP response message and transmits it back over the air to the Control Station.

The Control Station is configured to forward this onto the PC connected to it via USB.

A DCDM simplex channel cannot be used for data revert so the location updates will need to be sent on the same channel as voice.

Indoor location updates cannot be sent using single CSBK (Control Signalling Block) calls. They must be transmitted as standard data packets.

To perhaps increase the number of location updates per radio on this system, you could use DCDM and have half of the radio on timeslot 1 and the rest on timeslot 2. In this case you would need two Control Stations. In this case, the configuration is slightly different:

• Control Station 1 would be configured to operate on timeslot 1.
• Control Station 2 would be configured to operate on timeslot 2. The Radio IP will need to be changed to the next available 24-bit subnet (e.g. 192.168.11.0).
• Since they are probably both mobile radios and have good antennas, either or both of the Control Stations can be configured as DCDM timing leaders.

The alternative method would be to use MCDD. Although it hasnt seen an update for many years now, the MCDD was the original means to support multiple Control Stations. In this case, as a radio registers its presence on a specific channel, the Mobility Manager within MCDD detects which Control Station received the message and automatically updates the Application Server's IP routing table to direct all outbound data for that radio back through that exact Control Station.

Because radios can dynamically move from channel to channel based on user selection, the data application needs a way to track them transparently. When a radio powers up or changes to a new data-capable channel, it transmits an Automatic Registration Service (ARS) message. The Control Station sitting on that specific channel receives the ARS message and forwards it via its USB/IP connection to the Application Server where the DDMS (Presence Notifier) is running.

The Mobility Manager within MCDD operates as an NDIS Intermediate Driver on the PC. It sees the ARS message arriving from a specific Control Station's USB network adapter and dynamically updates the PC's internal IP routing table. It binds the field radio's unique IP address to the specific network interface of the Control Station that received the registration.

Because of this dynamic routing update, the process is completely transparent to the location tracking application. In this case, the application simply sends the location request (or any other data) as an outbound IP datagram addressed to the radio's IP address. The Windows routing table then automatically forwards the packet out the correct Control Station to reach the radio on its current channel.

Remember that if you attempt to use multiple Control Stations without installing DDMS and MCDD, the Application Server will have no dynamic method for routing messages. You would be forced to configure the PC to broadcast outbound data on all connected Control Stations simultaneously which is crazy. Or you would have to rely on static routes, meaning radios could only ever be contacted on one specific, hard-coded channel - which might be an option in some cases.

No matter which you choose to do, DDMS is definitely needed to ensure the application doesnt send requests to radios that aren't there.

As far as I can recall, MCDD supports up to 16 control stations.

With two (or more) control stations and DCDM, this setup will be able to support 25 radios per timeslot - assuming there is no voice and each radio send an update every 10 minutes. Since MOTOTRBO gives priority to voice, any data will have to wait and so the number of updates will drop.

This is how I would do it. If anyone would like to make suggestions on how this setup could be improved, please leave a comment. If I missed something in the explanation, please let me know.