Procedures for Radio Registration on Motorola ASTRO Conventional

Document Sample
Procedures for Radio Registration on Motorola ASTRO Conventional Powered By Docstoc
					       System User Information for OTAR and Packet Data Radio
    Interoperability on Motorola ASTRO Conventional Data Systems
Revision History:
1.00    Creation                                                                           June 20, 2001
1.1     First Draft for Public                                                             July 18, 2001


1.0 Scope
This document has been prepared in order to provide user level information to vendors and users who wish
to deploy mobile and portable radio units that will operate with a Motorola ASTRO data infrastructure.
This information is specifically useful for vendors and users planning to operate in conjunction with a
Motorola Key Management Facility implemented as P25 Packet data service with P25 OTAR (Over-the-
Air-Rekeying) messages.

2.0 System Description
A Motorola P25 ASTRO data system typically consists of two infrastructure elements, the RNC (Radio
Network Controller) and the WNG (Wireless Network Gateway). The WNG and multiple RNC's may
serve multiple RF Sites for wide area coverage topology. The RNC may have up to five encryption
modules associated with it for processing of encrypted packet data. Note that these encryption modules are
not required for OTAR operation.

3.0 Registration with the system
The infrastructure data system must somehow be aware of mobile and portable units that are valid members
of the system. For systems with multiple RF sites, the data system must keep track of which units are at
which sites. To address these requirements, the Motorola infrastructure products support two methods of
registering and tracking units with the system. These methods are referred to in this document as static and
dynamic registration

3.1 STATIC REGISTRATION:

With static registration, units are entered into the databases of the RNC and WNG by a system
administrator. This data entry step is done one time, typically when the system is being commissioned. A
large block of units can be added to the databases of both products via a single command or script,
minimizing operator interaction.

To accomplish the static registration requirement, mobile and portable units should generate ANY VALID,
PROPERLY FORMATTED P25 data message at any time. This can be when the unit changes RF channel
or at power-up. This simple procedure updates the RNC location and WNG routing databases. This will
maximize system efficiency by tracking the radio as it roams, and thereby to provide the most timely and
efficient delivery of unsolicited data messages originating from infrastructure host to radio.

With this method, the unit is always registered with the system, and registration information is stored in
non-volatile form so that even if the data system components are stopped and started, registration
information is preserved.

Note that with static registration, if very large systems are planned with multiple RNC's connected to a
single WNG, subscriber radio user action may be required to send the required data message which
completes the static registration requirement. A variety of implementation alternatives can exist with each
vendor in regard to how this message sequence is sent. This would only be required for subscriber radio
units that roam from RF sites serviced by one RNC to RF sites serviced by a different RNC.




27b69269-a4f5-47e2-af5c-a0d6d2f28bc4.docLast printed 2/9/2011 5:46:00 PM                          Page 1 of 3
3.2 DYNAMIC REGISTRATION

With the dynamic registration method, units are added to the WNG database just as with the static
registration method. This data entry step is done one time, typically when the system is being
commissioned.

To accomplish the dynamic registration requirement however, mobile and portable radio units generate a
specifically formatted registration message under certain specific situations. This dynamic registration
message protocol is Motorola - Proprietary and not currently documented in TIA/P25 publications. The
format of the message is being made available as an aid to interoperability between products produced by
different manufacturers. Note that use of this Motorola-Proprietary message presently requires licensing
from Motorola.

Motorola radios generate the registration message under the following circumstances:

            power-up
            RF channel change
            Exit from cryptographic keyload mode
            Exit from radio configuration/programming mode (Radio service software programming)

Note that this registration message uses confirmed delivery services and if a Motorola radio programmed to
use dynamic registration cannot successfully complete a registration sequence it cannot send OTAR or
packet data messages.

Motorola also defines a deregistration message that uses unconfirmed delivery services. This message is
sent under the following circumstances:

            immediately before power-down
            if operator has initiated channel change, message is sent on current channel before change is
             implemented
            entry into cryptographic key load mode
            entry into radio configuration /programming mode (Radio service software programming)

Registration request messages are sent under the circumstances noted above. The data infrastructure may
either respond with a REGISTRATION RESPONSE ACCEPTED message or a REGISTRATION
RESPONSE DENIAL message. In the case where registration is denied, the typical reason is that the unit
has not been entered into the WNG database as described above.


Note in regard to the use of Motorola MFID=$90:
Currently the data system infrastructure will only respond to MFID of $90 for Dynamic Registration. For
interoperability with Motorola systems using the Dynamic Registration protocol, vendors will need to send
MFID=$90 for dynamic unit registration. The use of Motorola MFID=$90 is NOT required for static unit
registration.




27b69269-a4f5-47e2-af5c-a0d6d2f28bc4.docLast printed 2/9/2011 5:46:00 PM                        Page 2 of 3
4.0 UNABLE TO DECRYPT MESSAGE

In an effort to make warm start procedures more user-friendly, Motorola has implemented a message for
radio and infrastructure products that indicates the unit’s inability to decrypt a data message. This message
is used primarily by the Key Management Facility (KMF) during OTAR transactions to automatically start
a warm start procedure if a target radio reports that it is unable to decrypt key management messages. This
message is sent inbound, unconfirmed. Note that the KMF product is capable of initiating a warm start
sequence WITHOUT this message, so use of this message is not required for a vendor’s radio to be
interoperable with a Motorola OTAR system. The "unable to decrypt" functional information is being
presented here as an aid to assuring usable operation between products produced by different
manufacturers.




27b69269-a4f5-47e2-af5c-a0d6d2f28bc4.docLast printed 2/9/2011 5:46:00 PM                          Page 3 of 3