When to NAI and when to not?

NAI (Network Application Interface) is a premium feature on all MOTOTRBO radios that allows a 3rd party application to address radios directly and not via a control station. A premium feature requires the purchase and activation of a software license. 

There are two types NAI licenses:

NAI Voice/CSBK. This allows a 3rd party application to pass voice calls as well as control messages (e.g. radio disable; Transmit Interrupt etc.) to/from the radio system. This would only (mostly) be used with applications such as Avtec Scout; TRBONET Plus and SmartPTT Plus.

NAI Data. This allows a 3rd party application to to send and receive data to/from radios. This includes things like Telemetry; Location (GNSS/Bluetooth); IMPRES Battery data; and text.

If NAI is not used, then the application will generally need to access the radio network via a control station (also known as a donor radio).

NAI Voice/Data is not needed on Capacity Max as there ate different licenses that enable voice and data access in this topology.

There are some limitations to what can be achieved with a control station. There are also situations where using NAI Voice/Data could be an overkill.

So when should you use a control station and what should you use NAI? Here are some points to consider when designing a MOTOTRBO system with 3rd party application:

Use NAI Voice/Data	Use a Control Station
IP Site Connect system has local area channels on which the dispatcher needs to talk/listen. And a gateway cannot be used.	Any system where there is only one talkgroup used by the dispatcher.
Any system where there is a large volume of radio-to-server data – either on a voice channel or on a data revert channel.	Any system, except Capacity Max,  where there is only a small amount
A Capacity Plus system where the dispatcher needs to talk on any talkgroup and/or there are sites with local talkgroups.	When the dispatch location is within RF range of one of the repeater sites.
When enhanced or single CSBK GPS is used.	When no data is used or the volume of radio-to-server data is small.
When data and voice contention is a concern.	When data and voice contention is not a concern.

In cases the dispatch location and nearest repeater are not within RF range of each other; or, in cases where there is a local talkgroup that must be monitored, Avtec Scout has an Outpost; TRBONET Plus has a Swift and SmartPTT Plus has a RG1000e. 

All of these are essentially a device that processes audio and data and sends this over IP. This allows a control station to be connected to the application server via IP. The device also relays the information on the radio display back to the application client and allows the user to access the radio buttons/menus (remote radio control).

If the control station is the destination for ARS and GPS, remember that while this radio is in a voice call, it cannot receive any data. In the case of ARS, the source radio will either wait or retry. In the case of GPS (location), the update from the radio will be delayed. In such cases, it may make sense to use two control stations - one for voice and one for data.

For data, the application only needs a USB connection. If the control station will be used for voice, the application host will need a sound card and a cable to bring audio from the radio to the sound card. 

If two (or more) control stations are used, this opens the possibility for using a data revert channel (i.e. using timeslot 1 for voice and timeslot 2 for radio-to-server data). Note that location requests may still need to be sent from the application on the "voice" control station.

If more than one control station is installed at a dispatch location, careful attention needs to be paid to managing RF interference - specifically desense.

Applications which require the NAI Data license will also use MNIS. This is a middleware application that acts as an interface between the wired IP network and wireless radio network. It allows the application to address radios using standard IP without needing to get involved with MOTOTRBO signaling.

There are many aspects to this part of system design, my suggestion would be to consult the application provider's documentation and the MOTOTRBO System Planner. If there is something I've missed, there is always the comments below.